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About this Book and the Library 


The Installation Guide provides an introduction to NetIQ Access Manager and describes the 
installation and upgrade procedures. 


Intended Audience 


This book is intended for Access Manager administrators. It is assumed that you have knowledge of 
evolving Internet protocols, such as: 


+ 


+ 


+ 


+ 


+ 


Extensible Markup Language (XML) 

Simple Object Access Protocol (SOAP) 

Security Assertion Markup Language (SAML) 

Public Key Infrastructure (PKI) digital signature concepts and Internet security 
Secure Socket Layer/Transport Layer Security (SSL/TLS) 

Hypertext Transfer Protocol (HTTP and HTTPS) 

Uniform Resource Identifiers (URIs) 

Domain Name System (DNS) 

Web Services Description Language (WSDL) 


Other Information in the Library 


The library provides the following information resources: 


+ 


+ 


+ 


NetIQ Access Manager 4.3 Best Practices Guide 
NetIQ Access Manager 4.3 Administration Guide 
NetIQ Access Manager 4.3 Developer Guide 


NOTE: Contact namsdk@netiq.com for any query related to Access Manager SDK. 
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About this Book and the Library 


About NetIQ Corporation 


We are a global, enterprise software company, with a focus on the three persistent challenges in your 
environment: Change, complexity and risk—and how we can help you control them. 


Our Viewpoint 


Adapting to change and managing complexity and risk are nothing new 


In fact, of all the challenges you face, these are perhaps the most prominent variables that deny 
you the control you need to securely measure, monitor, and manage your physical, virtual, and 
cloud computing environments. 

Enabling critical business services, better and faster 


We believe that providing as much control as possible to IT organizations is the only way to 
enable timelier and cost effective delivery of services. Persistent pressures like change and 
complexity will only continue to increase as organizations continue to change and the 
technologies needed to manage them become inherently more complex. 


Our Philosophy 


Selling intelligent solutions, not just software 


In order to provide reliable control, we first make sure we understand the real-world scenarios in 
which IT organizations like yours operate — day in and day out. That's the only way we can 
develop practical, intelligent IT solutions that successfully yield proven, measurable results. And 
that's so much more rewarding than simply selling software. 

Driving your success is our passion 


We place your success at the heart of how we do business. From product inception to 
deployment, we understand that you need IT solutions that work well and integrate seamlessly 
with your existing investments; you need ongoing support and training post-deployment; and you 
need someone that is truly easy to work with — for a change. Ultimately, when you succeed, we 
all succeed. 


Our Solutions 


¢ Identity & Access Governance 

e Access Management 

¢ Security Management 

¢ Systems & Application Management 
¢ Workload Management 

¢ Service Management 
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Contacting Sales Support 


For questions about products, pricing, and capabilities, contact your local partner. If you cannot 
contact your partner, contact our Sales Support team. 


Worldwide: www.netiq.com/about_netiq/officelocations.asp 
United States and Canada: 1-888-323-6768 
Email: info@netiq.com 
Web Site: www.netiq.com 


Contacting Technical Support 


For specific product issues, contact our Technical Support team. 


Worldwide: www.netig.com/support/contactinfo.asp 
North and South America: 1-713-418-5555 

Europe, Middle East, and Africa: +353 (0) 91-782 677 

Email: support@netiq.com 

Web Site: www.netiq.com/support 


Contacting Documentation Support 


Our goal is to provide documentation that meets your needs. If you have suggestions for 
improvements, click Add Comment at the bottom of any page in the HTML versions of the 
documentation posted at www.netiq.com/documentation. You can also email Documentation- 
Feedback@netiq.com. We value your input and look forward to hearing from you. 


Contacting the Online User Community 


Qmunity, the NetIQ online community, is a collaborative network connecting you to your peers and 
NetIQ experts. By providing more immediate information, useful links to helpful resources, and 
access to NetIQ experts, Qmunity helps ensure you are mastering the knowledge you need to realize 
the full potential of IT investments upon which you rely. For more information, visit http:// 
community.netig.com. 
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Installing Access Manager 


Before you start installation, evaluate how you want to implement Access Manager.You can install 
components on a single server (excluding Analytics Server) or on separate servers. For more 
information about installing other components, see Chapter 1, “Planning Your Access Manager 
Environment,” on page 13. 


The following is the sequence of installing Access Manager components: 


1 
2. 
3 


4. 


This part describes how to install Access Manager components and include the following chapters: 


+ 


+ 


+ 


. Administration Console 


Identity Server 


. Access Gateway 


Analytics Server 


Chapter 1, “Planning Your Access Manager Environment,” on page 13 
Chapter 2, “Installing the Administration Console,” on page 39 
Chapter 3, “Installing the Identity Servers,” on page 49 

Chapter 4, “Installing the Access Gateway,” on page 59 

Chapter 5, “Installing Analytics Server,” on page 71 


Chapter 6, “Installing Packages and Dependent RPMs on RHEL for Access Manager,” on 
page 85 


Chapter 7, “Uninstalling Components,” on page 89 
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1.1 


Planning Your Access Manager 
Environment 


This section includes the following topics: 


¢ Section 1.1, “Deployment Models,” on page 13 

¢ Section 1.2, “Access Manager Versus Access Manager Appliance,” on page 14 

¢ Section 1.3, “Network Requirements,” on page 21 

¢ Section 1.4, “Hardware Requirements,” on page 22 

¢ Section 1.5, “Recommended Installation Scenarios,” on page 22 

¢ Section 1.6, “Installing Access Manager Components in NAT Environments,” on page 24 
¢ Section 1.7, “Setting Up Firewalls,” on page 29 

¢ Section 1.8, “Protecting an Identity Server Through the Access Gateway,” on page 37 


Deployment Models 


Access Manager Appliance is a deployment model introduced from NetIQ Access Manager 3.2 
onwards. It includes all major components such as Administration Console, Identity Server, and 
Access Gateway in a single soft appliance. This solution differs from the other Access Manager 
model where all components can be installed on separate systems. Access Manager Appliance 
enables organizations to rapidly deploy and secure Web and enterprise applications. This simplifies 
access to any application. The reduced deployment and configuration time gives quick time to value 
and helps to lower the total cost of ownership. 


Some of the key differentiators that Access Manager Appliance offers over the Access Manager 
solution are: 

¢ Quick installation and automatic configuration 

¢ Single port configuration and common location to manage certificates 

+ Sample portal for administrator reference 

+ Fewer DNS names, SSL certificates, and IP addresses 

+ Reduced hardware requirements 


For details about these differentiators and other features of Access Manager Appliance, see 
Section 1.2, “Access Manager Versus Access Manager Appliance,” on page 14. 


The following diagrams describe differences between Access Manager and Access Manager 
Appliance: 
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Figure 1-1 Typical Deployment of Access Manager 
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Figure 1-2 Typical Deployment of Access Manager Appliance 
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1.2 Access Manager Versus Access Manager 
Appliance 
Both Access Manager and Access Manager Appliance deployment models use a common code 


base. But, the differences in the deployment method result in few similarities and differences in both 
models. The following table provides details to help you determine which solution fits your business: 


Table 1-1 Access Manager Versus Access Manager Appliance 


Feature Access Manager Appliance Access Manager 


Virtualization Support Supported on the virtual servers Supported on the virtual servers 
based on SUSE Linux Enterprise based on SUSE Linux Enterprise 
Server (SLES) 11 SP4 with 64-bit Server (SLES) 11 SP4, or SLES 12 
operating system x86-64 hardware. SP1 with 64-bit operating system 
x86-64 hardware. 
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Feature 


Host Operating System 


Component Installation Flexibility 


Administration Console Access 


Scalability and Performance 


High Availability 


Upgrade 


Disaster Recovery 


Access Manager Appliance 


A soft appliance that includes a pre- 
installed and configured SUSE 
Linux operating system. NetIQ 
maintains both the operating 
system and Access Manager 
patches through the patch update 
channel. 


Access Manager components such 
as Administration Console, Identity 
Server, and Access Gateway 
cannot be selectively installed or 
uninstalled. 


Administration Console is installed 
on Access Manager Appliance 
along with all other components. If 
you use two network interfaces, 
access to the Administration 
Console can be limited to the 
private IP network bound to the 
internal network. The public 
interface is bound to an externally 
accessible network. 


Scales vertically on adding CPU 
and memory resources to each 
node. 


For more information, see 
Performance and Sizing 
Guidelines. 


Supported 


You can upgrade from one version 
of Access Manager Appliance to 
another version. However, 
upgrading from Access Manager to 
Access Manager Appliance is not 
supported. 


You can use the backup and restore 
process to save your Access 
Manager Appliance configuration. 


Access Manager 


Operating System choice is more 
flexible. Install Administration 
Console, Identity Server, and 
Access Gateway on a supported 
operating system (SUSE, Red Hat, 
or Windows). The patch update 
channel maintains the patches for 
Access Manager. You must 
purchase, install, and maintain the 
underlying operating system. 


Each Access Manager component 
such as Administration Console, 
Identity Server, and Access 
Gateway are installed on 
independent host servers. Although 
the ability to install multiple 
components on a single host server 
exists, it is very limited and 
generally not recommended. A 
typical highly available deployment 
requires 6-8 or more virtual or 
physical servers (2 Administration 
Consoles, 2 Identity Servers, 2 
Access Gateways). 


Administration Console can be 
installed on an independent host 
inside your private network but can 
still securely manage Access 
Manager components that reside in 
your DMZ or external network. 


Scales both vertically and 
horizontally on adding nodes. 


For more information, see 
Performance and Sizing 
Guidelines. 


Supported 


You can upgrade from one version 
of Access Manager to another 
version. However, upgrading from 
Access Manager Appliance to 
Access Manager is not supported. 


You can use the backup and restore 
process to save your Access 
Manager configuration. 
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Feature 


Time to Value 
User Input required during 


installation 


Installation and Configuration 
Phases 


Mode of release 


NIC Bonding 


Networking: Port Details 


Networking: General 


Certificate Management 


Certificate Management: SAML 


Assertion Signing 


Associating different signing 
certificates for each service 
provider 


Access Manager Appliance 


Automates several configuration 
steps to quickly set up the system. 


Access Manager Appliance is a 


software appliance that takes only a 


few basic parameters as input. 
Several options assume default 
values. 


The installer takes care of 
configuration for each component. 
The system is ready for use after it 
is installed. 


Access Manager Appliance is 
released as a software appliance. 


IP address configuration is done 
through the Administration Console. 
So, NIC bonding is not supported. 


The Administration Console and 
Identity Server are accelerated and 
protected by Access Gateways. 
Only HTTPS port 443 is required to 
access the Access Manager 
Appliance through a firewall. 


Administration Console must be in 
DMZ, but access can be restricted 
through the private interface. 


Certificate management is 
simplified. All certificates and key 
stores are stored at one place 
making replacing or renewing 
certificates easier. 


Same certificate is used for all 
communication. (signing, 
encryption, and transport). 


Not supported 
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Access Manager 


Requires more time to install and 
configure as the components are on 
different servers. 


More flexibility during installation in 
terms of selectable parameters. 


Separate installation and 
configuration phases for each 
component. 


After installation, each Access 
Manager component is separately 
configured. 


Access Manager is delivered in the 
form of multiple operating system- 
specific binaries. 


NIC bonding can be done through 
the operating system and Access 
Manager in turn uses this 
configuration. 


Multiple ports need to be opened for 
deployment. 


As Administration Console is a 
separate device, access can be 
restricted or Administration Console 
can be placed in an internal 
network. 


Changes are required at multiple 
places to replace or renew 
certificates. 


As there are multiple key stores, 
you can configure different 
certificates for the communication. 


A unique signing certificate can be 
assigned to each service provider. 


In environments with a large 
number of trust relationships, this 
feature eases the process of 
replacing expiring certificates. 
Note: This is a feature that was 
introduced in Access Manager 3.2 
SP2. 


Feature 


Associating different certificates to 
Identity Server 


Sample Portal 


Ready-made Access Manager 


Access Manager Appliance 


Not applicable because the Identity 
Server is accelerated by the Access 
Gateway. 


After a successful installation, a 
sample Web portal is deployed for 
the administrator's reference. The 
administrator can access the 
sample portal by using the http:// 
hostname URL. This portal provides 
detailed example of Access 
Manager Appliance usage and 
policy configuration. 


The following configuration is 
automatically done when Access 
Manager Appliance is installed: 


+ Importing Identity Server and 
Access Gateway components. 


+ Automatic cluster creation of 
Identity Server and Access 
Gateway component. 


+ Automatic configuration of 
Identity Server to bring it to 
green state. 


+ Automatic configuration of 
Access Gateways and Identity 
Server association. 


+ Automatic service creation to 
accelerate or protect the 
Identity Server, Administration 
Console, and sample portal. 


As the inter-component 
configuration is automated, the 
administrator only needs to add the 
existing user store and accelerate, 
protect, sso-enable existing Web 
applications. 


Access Manager 


Supported. The Identity Server can 
be behind the Access Gateway or 
can be placed separately in the 
DMZ. 


Not available. 


Each component is manually 
configured and set up before Web 
applications can be federation 
enabled, accelerated, protected. 


Updating Kernel with Security 
Patches 


Supports installation of latest SLES You are fully responsible for all 
operating system security patches. operating system maintenance 
including patching. 
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Feature 


Clustering 


Access Manager Appliance 


For additional capacity and for 
failover, cluster a group of NetlQ 
Access Manager Appliances and 
configure them to act as a single 
server. 


You can cluster any number of 
Identity Servers and Access 
Gateways, and up to three of 
Administration Consoles. The first 
three nodes of Access Manager 
Appliance contain the 
Administration Console, Identity 
Server, and Access Gateway. 
Fourth installation onwards, the 
node has all components except for 
the Administration Console. 


A typical Access Manager 
Appliance deployment in a cluster is 
described in Figure 1-3 on page 19. 
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Access Manager 


For additional capacity and for 
failover, cluster a group of Identity 
Servers and configure them to act 
as a single server. You can create a 
cluster of Access Gateways and 
configure them to act as a single 
server. Fault tolerance can be 
achieved by installing up to two 
secondary consoles. 


To deploy the existing solution in a 
cluster mode, at least 6 systems 
are required. 


A typical Access Manager 
deployment in a cluster is described 
in Figure 1-4 on page 20. 


Figure 1-3 Access Manager Appliance Cluster 
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Figure 1-4 Access Manager Cluster 


-_ Can be clustered. 


General Guidelines 


¢ It is not possible to add an Access Gateway Service or Access Gateway Appliance to an Access 
Manager Appliance cluster. 

+ Deploying the Administration Console in a DMZ network limits access from a private interface or 
network. 
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+ It is recommended to not change the primary IP Address of an Access Manager. This may result 
in corruption of the configuration store. However, you can modify the Listening IP address of 
reverse proxy or the outbound IP address used to communicate with the Web server. For more 
information, see Changing the IP Address of Access Manager Devices in the NetIQ Access 
Manager 4.3 Administration Guide. 


+ You cannot have different certificates for signing, encryption in a Federation setup. 


¢ You cannot install any monitoring software to monitor statistics on an Access Manager 
Appliance. 


¢ Clustering between Access Manager and Access Manager Appliance is not supported. 


When to Choose Access Manager Appliance 
The following are common usage patterns when you can deploy Access Manager Appliance: 


+ You are interested in deploying Access Manager, but need fewer servers. 
+e You are still on iChain because you prefer a single-server solution. 


+ You are new to Access Manager and are interested in providing secure access, but want to 
avoid the long process of designing, installing, and configuring a full-fledged Web access 
management solution. 


+ You do not have a Web access management or federation solution and you are considering 
moving to a Web access management solution. 


e You represent a division of a large organization (for example, the Marketing division) that wants 
secure single sign-on access to a SaaS application such as Salesforce. 


¢ You want to reduce server hardware and management cost by consolidating Access Manager 
services on fewer servers. 


¢ You want to quickly set up a test environment to verify changes. 
¢ You want to quickly setup and evaluate Access Manager. 


1.3 Network Requirements 


In addition to the servers on which software is installed, your network environment needs to have the 
following: 


+ A server configured with an LDAP directory (eDirectory, Sun ONE, or Active Directory) that 
contains your system users. The Identity Server uses the LDAP directory to authenticate users 
to the system. 


+ Web servers with content or applications that need protection. 
¢ Clients with an Internet browser. 


e An L4 switch if you are going to configure load balancing. This can be hardware or software (for 
example, a Linux machine running Linux Virtual Services). 


¢ Static IP addresses for each machine used for an Access Manager component. If the IP address 
of the machine changes, the Access Manager component or components on that machine 
cannot start. 


+ Domain name server, which resolves DNS names to IP addresses and which has reverse 
lookups enabled. 


Access Manager devices know each other by their IP addresses, and some requests require 
them to match an IP address with the device's DNS name. Without reverse lookups enabled, 
these requests fail. In particular, Identity Servers perform reverse lookups to their user stores. If 
reverse lookups are not available, host table entries can be used. 
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e Network time protocol server, which provides accurate time to the machines on your network. 
Time must be synchronized within one minute among the components, or the security features of 
the product disrupt the communication processes. You can install your own or use a publicly 
available server such as pool.ntp.org. 


IMPORTANT: If time is not synchronized, users cannot authenticate and access resources. 


1.4 Hardware Requirements 


The hardware requirements for each component is added in the installation section for the respective 
components. The below table provides the link to hardware requirements for each component: 


Component Requirements in Linux Requirements in Windows 

Administration Console “Installation Requirements on “Installation Requirements on 
Linux” on page 39 Windows” on page 44 

Identity Server “Installation Requirements on “Installation Requirements on 
Linux” on page 50 Windows” on page 52 

Access Gateway “Linux Requirements” on page 65 “Windows Requirements” on 

page 67 
Analytics Server “System Requirements” on page 71 Not applicable 


1.5 Recommended Installation Scenarios 


The following scenarios provide an overview of the flexibility built into Access Manager. Use them to 
design a deployment strategy that fits the needs of your company. 


¢ Section 1.5.1, “Basic Setup,” on page 23 
¢ Section 1.5.2, “High Availability Configuration with Load Balancing,” on page 24 
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1.5.1 Basic Setup 


You need to protect the Administration Console from Internet attacks. It should be installed behind 
your firewall. For a basic Access Manager installation, you can install the Identity Server and the 
Access Gateway outside your firewall. Figure 1-5 illustrates this scenario: 


Figure 1-5 Basic Installation Configuration 
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1 Install the Administration Console. 


The Administration Console and the Identity Server are bundled in the same download file or 
ISO image. 


2 If your firewall is set up, open the ports required for the Identity Server and the Access Gateway 
to communicate with the Administration Console: TCP 1443, TCP 8444, TCP 1289, TCP 1290, 
TCP 524, TCP 636. 


For more information about these ports, see Section 1.7, “Setting Up Firewalls,” on 
page 29Chapter 1.7, “Setting Up Firewalls,” on page 29. 


3 Run the installation again and install the Identity Server on a separate server. 


Log in to the Administration Console and verify that the Identity Server installation was 
successful. 


4 Install the Access Gateway. 

Log in to the Administration Console and verify that the Access Gateway imported successfully. 
5 Install Analytics Server. 

Log in to Administration Console to verify that Analytics Server is imported successfully. 


6 Configure the Identity Server, Analytics Server, and the Access Gateway. See Configuring 
Access Manager in the NetIQ Access Manager 4.3 Administration Guide. 


In this configuration, the LDAP server is separated from the Identity Server by the firewall. Make 
sure you open the required ports. See Section 1.7, “Setting Up Firewalls,” on page 29. 


For information about setting up configurations for fault tolerance and clustering, see High Availability 
and Fault Tolerance in the NetIQ Access Manager 4.3 Administration Guide. 


Firewall protects the LDAP server and the Administration Console, both of which contain a permanent 
store of sensitive data. Web servers are also installed behind the firewall for added protection. The 
Identity Server is not much of a security risk, because it does not permanently store any user data. 
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1.5.2 


24 


1.6 


NetIQ has tested and recommends this configuration. We have also tested this configuration with an 
L4 switch in place of the router so that the configuration can support clusters of Identity Servers and 
Access Gateways. 


High Availability Configuration with Load Balancing 


Figure 1-6 illustrates a deployment scenario where Web resources are securely accessible from the 
Internet. The scenario also provides high availability because both Identity Servers and Access 
Gateways are clustered and have been configured to use an L4 switch for load balancing and fault 
tolerance. 


Figure 1-6 Clustering Configuration for High Availability 
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You can configure end users to communicate with Identity Servers and Access Gateways through 
HTTP or HTTPS. You can configure Access Gateways to communicate with Web servers through 
HTTP or HTTPS. Multiple Administration Consoles provide administration and configuration 
redundancy. 


This configuration is scalable. As the number of users increase and the demands for Web resources 
increase, you can easily add another Identity Server or Access Gateway to handle the load, then add 
the new servers to the L4 switch. When the new servers are added to the cluster, they are 
automatically sent the cluster configuration. 


Installing Access Manager Components in NAT 
Environments 


This chapter provides information about deploying Access Manager components in a multi-tenant or 
service provider environment, where Network Address Translation (NAT) protocol is used as one of 
the network configuration. Topics include: 

¢ Section 1.6.1, “Network Prerequisites,” on page 25 

¢ Section 1.6.2, “Network Setup Flow Chart,” on page 25 

¢ Section 1.6.3, “Installing Access Manager Components in NAT Environments,” on page 26 

¢ Section 1.6.4, “Configuring Network Address Translation,” on page 28 
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1.6.1 Network Prerequisites 


Service Provider Network Setup 


© Obtain Static IP addresses for Administration Console, Identity Server, and Analytics Server or 
Sentinel. If the IP address of the machine changes, the Access Manager components on that 
machine cannot start. 


O Install operating system, configure Network Time Protocol (NTP) server, and check connectivity. 


O NTP server, which provides accurate time to the machines on your network. Time must be 
synchronized within one minute among the components, or the security features of the product 
disrupt the communication processes. You can install your own or use a publicly available server 
such as pool.ntp.org. 


IMPORTANT: If time is not synchronized, users cannot authenticate and access resources and 
data corruption can also happen in user stores. 


O An L4 switch if you are going to configure load balancing. This can be hardware or software (for 
example, a Linux machine running Linux Virtual Services). 


O There should be IP connectivity between different Access Manager components. Because the 
components can be in different private networks, you can use NAT, VPNs, or combination of both 
to achieve connectivity. 


Customer Network Setup 


O A server configured with an LDAP directory (eDirectory 8.8.8.8 or later, Sun ONE, or Active 
Directory) that contains your system users. The Identity Server uses the LDAP directory to 
authenticate users to the system. 


1 Domain name server, which resolves DNS names to IP addresses and which has reverse 
lookups enabled. 


Access Manager devices know each other by their IP addresses, and some requests require 
them to match an IP address with the device's DNS name. Without reverse lookups enabled, 
these requests fail. In particular, Identity Servers perform reverse lookups to their user stores. If 
reverse lookups are not available, host table entries can be used. 


O Obtain Static IP addresses for Administration Console, Identity Server, and Analytics Server or 
Sentinel. If the IP address of the machine changes, the Access Manager components on that 
machine cannot start. 


O There should be IP connectivity between different Access Manager components. Because the 
components can be in different private networks, you can use NAT, VPNs, or combination of both 
to achieve connectivity. 


1.6.2 Network Setup Flow Chart 


The network setup flow chart provides information about installing Access Manager components and 
configuring NAT in a multi-tenant or service provider network. 
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Figure 1-7 Network Setup Flow Chart 
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1.6.3 Installing Access Manager Components in NAT 
Environments 


Installing Access Manager in the NAT environment consists of the following steps: 


. “Installing the Administration Console” on page 26. 
. “Configuring Global Settings” on page 27 
. “Installing the Identity Servers” on page 49 
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. “Installing the Access Gateway” on page 59 


1.6.3.1 Installing the Administration Console 


For installation requirements, see “Installing the Administration Console” on page 39. 


1 Before installing Access Manager components, check the network connectivity across these 
machines. 

2 Verify the link latency and ensure that it is less than 100 milliseconds. 
If the link latency is greater than 100ms, it might lead to performance degradation. 

3 Synchronize time across all Access Manager components. 
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1.6.3.2 


1.6.3.3 


The primary Administration Console should be configured to synchronize time with the corporate 
Network Time Protocol (NTP) server. The remaining machines should be configured to 
synchronize time with the primary Administration Console. 


3a Add the following entry to the /etc/crontab file on the primary Administration Console: 
*/5 * * * * root sntp -P no -r <corporate NTP_Server> >/dev/null 2>&1 

3b Add the following entry to the /etc/crontab file of other Access Manager machines: 
*/5 * * * * root sntp -P no -r <Primary_Admin_Console_IP> >/dev/null 2>&1 


4 Install the primary Administration Consoles by providing the listening IP address for the primary 
Administration Console. 


For more information about installing the Administration Console, see the “Installing the 
Administration Console on Windows’ on page 44. 


5 Install the secondary Administration Console and repeat the above procedures for secondary 
Administration Console IP address. 


6 Continue with Section 1.6.3.2, “Configuring Global Settings,” on page 27 to add both the primary 
and secondary Administration Consoles to the Global Settings configuration. 


Configuring Global Settings 


You need to map the private IP address of the Administration Console and to the public NAT IP 
address. You need to specify the NAT IP addresses before importing the Identity Server and the 
Access Gateway. You have to specify the NAT IP Addresses prior to importing devices. The devices 
that cannot reach the Private Administration Console IP address will use the NAT IP address. 

Log in to the Administration Console. 

Select Access Manager > Global Settings. 

Click New. 


Select the Administration Console Listening IP address from the drop-down list. 
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Specify the corresponding Public NAT IP address. 


If you do not specify a Public NAT IP address or if a mapping already exists for the selected 
Administration Console IP address, the following message is displayed: 


IP Address is not valid 


6 Click OK to continue and apply the configuration changes. 


Installing and Configuring the Identity Server 


For information about how to install the Identity Server, see “Installing the Identity Servers” on 
page 49. 


User stores are LDAP directory servers to which end users authenticate. You must specify an initial 
user store when creating an Identity Server configuration. You use the same procedure for setting up 
the initial user store, adding a user store, or modifying an existing user store. 


For information about how to configure the Identity Server, see Configuring an Identity Server in the 
NetIQ Access Manager 4.3 Administration Guide. 
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1.6.3.4 


1.6.4 


1.6.4.1 


1.6.4.2 


Installing and Configuring the Access Gateway 


For information about how to install Access Gateway, see “Installing the Access Gateway” on 
page 59. 


When you are setting up the Access Gateway to protect Web resources, you create and configure 
reverse proxies, proxy services, and protected resources. The authentication contract, authentication 
procedure, Authorization policy, Identity Injection policy, and Form Fill policy are configured at the 
resource level so that you can enable exactly what the resource requires. 


For information about configuring Access Gateway, see Configuring Access Gateway in the NetlQ 
Access Manager 4.3 Administration Guide. 


Configuring Network Address Translation 


NetIQ Access Manager can be configured by using Network Address Translation (NAT), which 
enables the communication between the Administration Console from local network to other Access 
Manager devices such as Identity Server and Access Gateway. The devices can be in the external 
network or in another private network. The NAT address needs be to configured in router. 


See your router documentation for more information. 


¢ Section 1.6.4.1, “Configuring the Administration Console Behind NAT,” on page 28 
¢ Section 1.6.4.2, “Configuring Identity Server and Access Gateway Behind NAT,” on page 28 


Configuring the Administration Console Behind NAT 


1 Log in to the Administration Console. 

2 Go to Access Manager > Global Settings, then click New. 

3 Select an IP address from the Administration Console Public IP Address list. 
This list contains primary and secondary Administration Console IP addresses. 


4 Enter the respective NAT IP address for primary and secondary Administration Console in 
Public NAT IP Address. 


NOTE: If the NAT IP address is not provided or if a mapping exists for the selected 
Administration Console IP, a message IP Address is not valid is displayed. 


5 Click OK. 
The Administration Console NAT IP is shared to other Access Manager devices. 


For more information about configuring NAT, see Mapping the Private IP Address to Public IP 
Address in the NetIQ Access Manager 4.3 Administration Guide. 


Configuring Identity Server and Access Gateway Behind NAT 


During installation, the system prompts the following message to specify the NAT address for the 
component: 


Is local NAT available for the <device name> y/n? [n]: 


Enter Y and specify the NAT address. This enables the Administration Console to use this NAT 
address when communicating to this device. 
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Alternatively, if the device is already installed, then run the reimport_nidp.sh or reimport_ags.sh 
script to specify the NAT address. 


1.7 Setting Up Firewalls 


Access Manager should be used with firewalls. Figure 1-8 illustrates a simple firewall setup for a 
basic Access Manager configuration of an Identity Server, an Access Gateway, and an Administration 
Console. 


Figure 1-8 Access Manager Components between Firewalls 
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The first firewall separates the Access Manager from the Internet, allowing browsers to access the 
resources through specific ports. The second firewall separates Access Manager components from 
Web servers they are protecting and the Administration Console.This is one of many possible 
configurations. This section describes the following: 


¢ Section 1.7.1, “Required Ports,” on page 29 
¢ Section 1.7.3, “Sample Configurations,” on page 35 


1.7.1 Required Ports 


The following tables list the ports that need to be opened when a firewall separates one component 
from another. Some combinations appear in more than one table. This allows you to discover the 
required ports whether a firewall is separating a component from the Administration Console or a 
firewall is separating an Administration Console from the component. 


With these tables, you should be able to place Access Manager components of your system 
anywhere within your existing firewalls and know which ports need to be opened in the firewall. 
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Table 1-2 When a Firewall Separates an Access Manager Component from a Global Service 


Component 


NTP Server 


DNS Servers 


Remote Linux Administration 
Workstation 


Remote Windows Administration 
Workstation 


Port 


UDP 123 


UDP 53 


TCP 22 


Configurable 


Description 


Access Manager components must have time 
synchronized else the authentication fails. We 
recommend that you configure all components to 
use an network time protocol (NTP) server. 
Depending upon where your NTP server is located, 
you might need to open UDP 123, so that Access 
Manager components can use the NTP server. 


Access Manager components must be able to 
resolve DNS names. Depending upon where your 
DNS servers are located, you might need to open 
UDP 53, so that Access Manager components can 
resolve DNS names. 


If you want to use SSH for remote administration of 
Access Manager components, open TCP 22 to 
allow. 


If you want to use RDP or VNC for remote 
administration of Access Manager components, 
open the ports required by your application from the 
remote administration workstation to your Access 
Manager components. You need to open ports for 
console access and for file sharing. 


For console access, VNC usually uses TCP 5901 
and RDP uses TCP 3389. For file sharing, UDP 
135-139 are the default ports. 


Table 1-3 When a Firewall Separates the Administration Console from a Component 


Component 


Access Gateway, Identity Server 


Port 


TCP 1443 


TCP 8444 


TCP 1290 


TCP 524 


TCP 636 


HTTP 2443 
HTTP 8443 
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Description 


For communication from the Administration Console 
to the devices. 


For communication from devices to the 
Administration Console. 


For communication from devices to the Syslog 
server on the Administration Console. 


For NCP certificate management with NPKI. The 
port needs to be opened so that both the device and 
the Administration Console can use the port. 


For secure LDAP communication from devices to 
the Administration Console. 


For the installer to communicate with the 
Administration Console. You can close these port 
after installation is complete. 


Component 


Importing an Access Gateway 
Appliance 


LDAP User Store 


Administration Console 


Browsers 


Port 


ICMP 


TCP 524 


TCP 636 


TCP 524 


TCP 636 
TCP 8080, 8443 
TCP 705 


UDP 161 


TCP 8080 


TCP 8443, 2443, 
2080. 


TCP 8028, 8030 


Description 


During an import, the Access Gateway Appliance 
sends two pings through ICMP to the Administration 
Console. When the import has finished, you can 
disable the ICMP echo requests and echo replies. 


Required only if the user store is eDirectory. When 
configuring a new eDirectory user store, NCP is 
used to enable Novell SecretStore by adding a 
SAML authentication method and storing a public 
key for the Administration Console. It is not used in 
day-to-day operations. 


For secure LDAP communication from 
Administration Console to User Store. 


Required to synchronize the configuration data 
store. 


Required for secure LDAP communication. 
Used for Tomcat communication. 


Used by Sub Agent-Master Agent communication 
inside the Administration Console. 


Used for communication by an external Network 
Monitoring System with the Administration Console 
by using SNMP. 


For HTTP communication from browsers to the 
Administration Console. 


For HTTPS communication from browsers to the 
Administration Console. 


NOTE: 2443 and 2080 are optional ports required 
when the Administration Console and Identity 
Server are collocated. 


To use iMonitor or DSTrace from a client to view 
information about the configuration store on the 
Administration Console. 


Table 1-4 When a Firewall Separates the Identity Server from a Component 


Component 


Access Gateway 


Port 


TCP 8080 or 8443 


TCP 80 or 443 


Description 


For authentication communication from the Access 
Gateway to the Identity Server. The default ports for 
the Identity Server are TCP 8080 and 8443. They 
are configurable. You need to open the port that you 
configured for the base URL of the Identity Server. 


For communication from the Identity Server to ESP 
of the Access Gateway. This is the reverse proxy 
port that is assigned to be ESP (see the Reverse 
Proxy /Authentication page). This is usually port 80 
or 443. 
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Component 


Administration Console 


Identity Server 


LDAP User Stores 


Service Providers 


Browsers 


CRL and OCSP Servers 


Active Directory Server with 
Kerberos 


Port 


TCP 1443 


TCP 8444 


TCP 1290 


TCP 524 


TCP 636 


TCP 8443 or 443 


TCP 7801 


TCP 636 


TCP 8445 


TCP 8446 


TCP 8080 


TCP 8443 


Configurable 


TCP 88, UDP 88 
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Description 


For communication from the Administration Console 
to devices. This is configurable. 


For communication from the Identity Server to the 
Administration Console. 


For communication from devices to the Syslog 
server on the Administration Console. 


For NCP certificate management with NPKI from 
the Identity Server to the Administration Console. 


For secure LDAP communication from the Identity 
Server to the Administration Console. 


For HTTPS communication. You can use iptables to 
configure this for TCP 443. See Section 3.5, 
“Translating the Identity Server Configuration Port,” 
on page 54. 


For back-channel communication with cluster 
members. 


This port is configurable. 


For secure LDAP communication from the Identity 
Server to the LDAP user store. 


If you have enabled identity provider introductions, 
open a port to allow HTTPS communication from 
the user’s browser to the service provider. 


If you have enabled identity provider introductions, 
open a port to allow HTTPS communication from 
the user’s browser to the service consumer. 


For HTTP communication from a browser to the 
Identity Server. You can use iptables to configure 
this for TCP 80. SeeSection 3.5, “Translating the 
Identity Server Configuration Port,” on page 54. 


For HTTPS communication from a browser to the 
Identity Server. You can use iptables to configure 
this for TCP 443. See Section 3.5, “Translating the 
Identity Server Configuration Port,” on page 54. 


If you are using x.509 certificates that include an 
AlA or CRL Distribution Point attribute, you need to 
open the port required to talk to that server. Ports 
80/443 are the most common ports, but the LDAP 
ports 389/636 can also be used. 


For communication with the KDC on the Active 
Directory Server for Kerberos authentication. 


Table 1-5 When a Firewall Separates the Access Gateway from a Component 


Component 


Identity Server 


Administration Console 


Access Gateway 


Browsers/Clients 


Web Servers 


Port 


TCP 8080 or 8443 


TCP 80 or 443 


TCP 1443 


TCP 8444 


TCP 1290 


TCP 524 


TCP 636 


TCP 7801 


TCP 80 or 443 


TCP 80 


TCP 443 


TCP 80 


TCP 443 


Description 


For authentication communication from the Access 
Gateway to the Identity Server. The default ports 
are TCP 8080 and 8443, which are configurable. 
You need to open the port of the base URL of the 
Identity Server. 


For communication from the Identity Server to ESP 
of the Access Gateway. This is the reverse proxy 
port that is assigned to be ESP (see the Reverse 
Proxy /Authentication page). This is usually port 80 
or 443. 


For communication from the Administration Console 
to the Access Gateway. This is configurable. 


For communication from the Access Gateway to the 
Administration Console. 


For communication from devices to the Syslog 
server on the Administration Console. 


For NCP certificate management with NPKI from 
the Access Gateway to the Administration Console. 


For secure LDAP communication from the Access 
Gateway to the Administration Console. 


For back-channel communication with cluster 
members. 


This port is configurable. It is set by the Identity 
Server cluster configuration that the Access 
Gateway trusts. See Configuring a Cluster with 
Multiple Identity Servers in the NetlQ Access 
Manager 4.3 Administration Guide. 


For communication among Embeded Service 
Providers (ESP) of the Access Gateway cluster 
memebers. This is the reverse proxy port that is 
assigned to be ESP (see the Reverse Proxy / 
Authentication page). This is usually port 80 or 443. 
This port is configurable. 


For HTTP communication from the client to the 
Access Gateway. This is configurable. 


For HTTPS communication from the client to the 
Access Gateway. This is configurable. 


For HTTP communication from the Access Gateway 
to the Web servers. This is configurable. 


For HTTPS communication from the Access 
Gateway to Web servers. This is configurable. 
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Table 1-6 When a Firewall Separates Analytics Server from Administration Console or any Services 


Component 


Administration Console 


Browsers 


Browsers 


Syslog 


Control Center 


Remote Linux Administration 


Workstation 


High availability configuration 


Port 


TCP 1444 


TCP 8445 


TCP 8443 


TCP 1468 


TCP 10013 


TCP 22 


TCP 7360 


Description 


For communication between Administration 
Console and Analytics Server. 


For HTTPS communication with Analytics Server for 
Analytics Dashboard. 


For HTTPS communication with Analytics Server for 
Reports console. 


For updating Syslog messages from Access 
Manager components to Analytics Server. 


For communicating from a computer to the control 
center on Analytics Server. 


For communication from your remote administration 
workstation to Analytics Server. 


For communicating between the servers in 
Analytics server high availability mode. 


NOTE: On SLES, you can use YaST to configure UDP ports and internal networks. 


1.7.2 Restricted Ports 


The following ports are reserved for internal use only and other applications should not use these 


ports: 


22 
111 
524 
1443 
2443 
3443 
8028 
8030 
8080 
8443 
8444 
9000 
9001 
55982 
61222 
61613 
61616 
61617 


If required, use port redirection by using IP tables. 
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1.7.3 


1.7.3.1 


Sample Configurations 


¢ Section 1.7.3.1, “Access Gateway and Identity Server in DMZ,” on page 35 


¢ Section 1.7.3.2, “A Firewall Separating Access Manager Components from the LDAP Servers,” 
on page 36 


Access Gateway and Identity Server in DMZ 
¢ “First Firewall” on page 35 
¢ “Second Firewall” on page 35 

First Firewall 


If you place a firewall between browsers and Access Gateway and Identity Server, you need to open 
ports so that browsers can communicate with the Access Gateway and the Identity Server and the 
Identity Server can communicate with other identity providers. 


See, Figure 1-8 on page 29 


Table 1-7 Ports to Open in the First Firewall 


Port Purpose 
TCP 80 For HTTP communication. 
TCP 443 For HTTPS communication. 


Any TCP port assigned to a reverse proxy or tunnel. 


TCP 8080 For HTTP communication with the Identity Server. For information about redirecting the 
Identity Server to use port 80, see Section 3.5, “Translating the Identity Server 
Configuration Port,” on page 54. 


TCP 8443 For HTTPS communication with the Identity Server. For information about redirecting the 
Identity Server to use port 443, see Section 3.5, “Translating the Identity Server 
Configuration Port,” on page 54. 


TCP 8445 For HTTP Identity Provider introductions. If you do not enable Identity Provider 
introductions, you do not need to open this port. 


TCP 8446 For HTTPS Identity Provider introductions. If you do not enable Identity Provider 
introductions, you do not need to open this port. 


Second Firewall 


The second firewall separates Web servers, LDAP servers, and the Administration Console from the 
Identity Server and the Access Gateway. You need the following ports opened in the second firewall: 
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Table 1-8 Ports to Open in the Second Firewall 


Port Purpose 
TCP 80 For HTTP communication with Web servers. 
TCP 443 For HTTPS communication with Web servers. 


Any TCP connect port assigned to a Web server or to a tunnel. 


TCP 1443 For communication from the Administration Console to the devices. 
TCP 8444 For communication from the devices to the Administration Console. 
TCP 1290 For communication from the devices to the Syslog server installed on the Administration 


Console. If you do not enable auditing, you do not need to open this port. 


TCP 524 For NCP certificate management in NPKI. The port needs to be opened so that both the 
device and the Administration Console can use the port. 


TCP 636 For secure LDAP communication of configuration information. 


A Firewall Separating Access Manager Components from the LDAP 
Servers 


You can configure your Access Manager components so that your Administration Console is on the 
same side of the firewall as your Access Manager components and have a firewall between them and 
the LDAP servers. 


Figure 1-9 A Firewall Separating the Administration Console and the LDAP Server 
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In this configuration, you need to have the following ports opened in the second firewall for the 
Administration Console and the Identity Server. 
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Table 1-9 Ports to Open in the Second Firewall 


Ports Purpose 


TCP 636 For secure LDAP communication. This is used by the Identity Server and the 
Administration Console. 


TCP 524 For configuring eDirectory as a new User Store. NCP is used to enable SecretStore by 
adding a SAML authentication method and storing a public key for the Administration 
Console. During day-to-day operations, this port is not used. If your LDAP server is Active 
Directory or Sun ONE, this port does not need to be opened. 


Protecting an Identity Server Through the Access 
Gateway 


For security reasons, you might want to set up your Access Manager configuration so that the Identity 
Server is a resource protected by an Access Gateway. This configuration reduces the number of 
ports you need to open between the outside world and your network. Figure 1-10 illustrates such a 
configuration. 


Figure 1-10 Identity Servers behind an Access Gateway 
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With this configuration, you need an L4 switch to cluster the Access Gateways. However, you do not 
need an L4 switch to cluster the Identity Servers. When the Identity Server is configured to be a 
protected resource of the Access Gateway, the Access Gateway uses its Web server communication 
channel. Each Identity Server in the cluster must be added to the Web server list, and the Access 
Gateway uses its Web server load balancing and failover policies for the clustered Identity Servers. 


Limitations: The following features are not supported with this configuration: 


¢ The Identity Server cannot respond to Identity Provider introductions. 


+ Federation to an external service provider that requires the artifact profile with SOAP/Mutual 
SSL binding cannot be supported with this configuration. 


+ The proxy service that is protecting the Identity Server cannot be configured to use mutual SSL. 
For example with this configuration, X.509 authentication cannot be used for any proxy service. 
To perform X.509 authentication (which is a form of mutual SSL), a user's browser must have 
direct access to the Identity Server. 


+ The proxy service that is protecting the Identity Server cannot be configured to use NMAS. 


For configuration details, see Configuring a Protected Identity Server Through Access Gateways in 
the NetIQ Access Manager 4.3 Administration Guide. 
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2.1 


2.1.1 


Installing the Administration Console 


Administration Console is the first component you install. If you have iManager installed for other 
products, you still need to install this version on a separate server. The Administration Console is 
installed with an embedded version of eDirectory, which is used as the configuration store for Access 
Manager. 


For a functioning system, you need an Administration Console for configuration and management, an 
Identity Server for authentication, and an Access Gateway for protecting resources. The 
Administration Console must be installed before you install any other Access Manager devices. 


After you have installed the Administration Console, the installation scripts for the other components 
(Identity Server and Access Gateway) auto-import their configurations into the Administration 
Console. 


This chapter explains how to install and configure the Administration Console. Topics include: 


¢ Section 2.1, “Installing the Administration Console on Linux,” on page 39 

¢ Section 2.2, “Installing the Administration Console on Windows,” on page 44 

¢ Section 2.3, “Logging In to the Administration Console,” on page 47 

¢ Section 2.4, “Enabling the Administration Console for Multiple Network Interface Cards,” on 
page 48 


For information about installing a secondary Administration Console and fault tolerance, see Installing 
Secondary Versions of Administration Console in the NetIQ Access Manager 4.3 Administration 
Guide. 


Installing the Administration Console on Linux 


¢ Section 2.1.1, “Installation Requirements on Linux,” on page 39 
¢ Section 2.1.2, “Installation Procedure,” on page 41 


Installation Requirements on Linux 


+ 4 GB RAM. 
¢ Dual CPU or Core (3.0 GHz or comparable chip) 
+ 100 GB hard disk 


The hard disk should have ample space for logging in a production environment. This disk space 
must be in the local server not in the remote server. 


+ One of the following operating systems: 


+ SUSE Linux Enterprise Server (SLES) 11 SP4 and SLES 12 SP1 with 64-bit operating 
system x86-64 hardware (physical or virtual). Ensure that the following packages are 
installed: 
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Package 


perl-gettext, gettext-runtime 


python 


compat 


binutils 


rsyslog 


rsyslog-module-gtls 


libXtst6-32bit 


Description 


The required library and tools to create and maintain 
message catalogs. 


The basic Python library. 


Libraries to address compatibility issues. For 
information on enabling this repository, see TID 
7004701 (http:/www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld= 
7004701 &sliceld=1&docTypelD=DT_TID_1_1&dialogl 
D=689264208&stateld=0%200%20130264119) 


Use the following command to verify: 
rpm -qa | grep <package name> 
Use YaST to install the packages. 


The required set of tools to create and manage binary 
programs. 


The required software for forwarding audit messages. 


The required TLS encryption support module for 
rsyslog. 


Has dependency on iManager 


+ Red Hat Enterprise Linux (RHEL) 6.8 and 7.2 (64-bit) (physical or virtual). For installing the 
RHEL packages, see Appendix 6, “Installing Packages and Dependent RPMs on RHEL for 


Access Manager,” on page 85. 


+ (Conditional) For Access Manager 4.3 Service Pack 3 (4.3.3), installation is also supported 
on RHEL 7.4 and SLES 12 SP3. 


Install the latest net -snmp package from the SLES or RedHat update channel. 
Zip and unzip utilities must be available for the backup and restore procedure. 
Ports 389 and 636 need to be free. 


Static IP address (if the IP address changes after devices have been imported, these devices 
can no longer communicate with the Administration Console.) 


The tree for the configuration store is named after the server on which you install the 
Administration Console. Check the hostname and rename the machine if the name is not 
appropriate for a configuration tree name. 


The Administration Console can be installed on the same server as the Identity Server. If you are 
planning to install an L4 switch on a SLES server by using the Linux Virtual Services software, 
you can also install the Administration Console on this server. 


Network requirements: See Section 1.3, “Network Requirements,” on page 21. 


IMPORTANT: You cannot install the following with the Administration Console: 


+ OpenLDAP server. If it is installed, you must un-install it. 


+ LDAP software such as eDirectory. 


+ Other version of iManager. You also cannot add other iManager product plug-ins to this 


Administration Console. 
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+ Because of library update conflicts, you cannot install Access Manager on a Linux User 
Management (LUM) machine. 


+ JRE. If you have a version installed, uninstall it. 


2.1.1.1 Browser Support 


¢ Internet Explorer 11 and later 
¢ Mozilla Firefox 

+ Chrome 

¢ Safari 


Browser pop-ups must be enabled to use the Administration Console. 


2.1.2 Installation Procedure 


Installation time: about 20 minutes. 


What you need to create during installation A username and password for the Administrator. 


NOTE: If the Administration Console and the Identity Server are installed on different servers, both 
use 8080 and 8443 ports. If the Administration Console and the Identity Server are installed on the 
same server, Identity Server uses 8080 and 8443 ports and Administration Console uses 2080 and 
2443 ports. 


1 If you have Red Carpet or auto update running, stop these programs before you install the 
Administration Console. 


2 Verify that the machine meets the minimum requirements. See Section 2.1.1, “Installation 
Requirements on Linux,” on page 39. 


3 Open a terminal window. 
4 Access the install script as root: 
4a Ensure that you have downloaded the software or you have the CD available. 
For software download instructions, see the release-specific Release Notes. 
4b Do one of the following: 
+ Insert the CD into the drive, then navigate to the device. Specify the following: 
cd /media 


Change to your CD-ROM drive, which is usually cdrom but can be something else such 
as cdrecorder or dvdrecorder, depending on your hardware. 


+ If you downloaded the tar.gz file, unzip it by using the following command: 
tar -xzvf <filename> 


4c Change to the novell-access-manager directory. 


oa 


At the command prompt, specify the following: 
./install.sh 
Ensure that you have adequate space in the system before you proceed with installation. 


o 


When you are prompted to install a product, select 1. Install Administration Console and then 
press Enter. 
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7 


10 


11 


12 


Review and accept the License Agreement. 

Novell Base and JDK for NetIQ are installed. 

(Optional) The installer displays a warning if the host name of the system is mapped to the IP 
address 127.0.0.2 in the /etc/hosts file: 


An entry of 127.0.0.2 in the /etc/hosts file affects the Access Manager 
functionality. Do you want to proceed with removing it (y/n) [y] 
Specify Y to proceed. 


The host name mapping to 127.0.0.2 may cause certain Access Manager processes to 
encounter errors when they attempt to resolve the host name of the machine. To avoid these 
problems, remove the 127.0.0.2 entry from the/etc/hosts file. 


Specify whether this is a primary Administration Console in a failover group. The first 
Administration Console installed becomes the primary console: 


You can install up to three Administration Consoles for replication and failover purposes. If this is 
not the primary console, you must provide the IP address of the primary Administration Console. 


Specify the administration username. 


Press Enter to use admin as the default admin username, or change this to a username of your 
choice. 


NOTE 


+ The Administration Console username does not accept special characters # (hash), & 
(ampersand), and ()(round brackets). 


+ If you are installing secondary Administration Console, the username must be from the 
o=novell container. If the username is from any other container, the installer fails to install 
Administration Console. 


Specify the administration password. 
Use alphanumeric characters only. 


NOTE: The Administration Console password does not accept special characters : (colon) and 
" (double quotes). 


Confirm the password, then wait for the system to install components. 
This may take several minutes depending on the speed of your hardware. 


NOTE: Platform Agent and Novell Audit are not supported from Access Manager 4.2 onwards. 
The installation no longer installs Platform Agent and Novell Audit for auditing. If you upgrade 
from an older version of Access Manager to the latest version, Platform Agent is still available. It 
is recommended to use Syslog for auditing. 


The following components are installed: 


Component Description 
Syslog Responsible for packaging and forwarding the audit 


log entries to the configured Syslog Server. For 
more information, see Enabling Auditing in the 
NetIQ Access Manager 4.3 Administration Guide. 
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Component 


Tomcat for NetlQ 


Access Manager Configuration Store 


iManager 


Administration Console 


Identity Server Administration Plug-In 


13 Record the login URL. 


Description 


NetIQ packaging of the Java-based Tomcat Web 
server used to run serviets and JavaServer Pages 
(JSP) associated with NetIQ Access Manager Web 
applications. 


An embedded version of eDirectory used to store 
user-defined server configurations, LDAP attributes, 
Certificate Authority keys, certificates, and other 
Access Manager attributes that must be securely 
stored. 


The Web-based Administration Console that 

provides customized and secure access to server 
administration utilities. It is a modified version and 
cannot be used to manage other eDirectory trees. 


A modification of iManager that enables 
management of all aspects of Access Manager. 
This component is not a standard iManager plug-in. 
It significantly modifies the tasks that iManager can 
perform. 


Works in conjunction with the Administration 
Console to specifically manage the Identity Server. 


When installation completes, the login URL is displayed. It looks similar to the following: 


http://10.10.10.50:8080/nps 


Use this to configure Access Manager compone 


nts. 


14 Continue with “Configuring the Linux Administration Console Firewall” on page 43. 


Configuring the Linux Administration Console Firewall 


Before you can install other Access Manager components and import them into the Administration 
Console, or before you can log in to the Administration Console from a client machine, you must first 


configure the firewall on the Administration Console. 


1 Click Computer > YaST > Security and Users > 
This launches the Firewall Configuration screen 
2 Click Allowed Services > Advanced. 


3 Inthe TCP Ports field, specify the ports to open. 


Firewall. 


(Conditional) If you are installing the Administration Console and Identity Server on different 


machine, list the following additional ports in the 
+ 8080 
+ 8443 
+ 3080 
+ 3443 


TCP Ports field: 
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(Conditional) If you are installing the Administration Console and Identity Server on the same 
machine, list the following additional ports in the TCP Ports field: 


+ 2080 
+ 2443 


(Conditional) To import an Access Gateway into the Administration Console, list the following 
additional ports in the TCP Ports field: 


+ 1443 
+ 8444 
+ 1289 
+ 1290 
+ 524 
+ 636 
If you are importing an Access Gateway Appliance, specify icmp in the IP Protocols field. 
For specific information about the ports listed in Step 3 and Step 4, see Table 1-3 on page 30. 


NOTE: The Administration Console is accessible on ports 2080 (HTTP) and 2443 (HTTPs) when 
Identity Server is installed on the same machine. 


Restart Tomcat by running the following commands from the Administration Console command 
line. 


/etc/init.d/novell-ac stop 


/etc/init.d/novell-ac start 


6 Continue with Section 2.3, “Logging In to the Administration Console,” on page 47. 


2.2 Installing the Administration Console on Windows 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


Section 2.2.1, “Installation Requirements on Windows,” on page 44 


Section 2.2.2, “Installation Procedure,” on page 45 


Installation Requirements on Windows 


4 GB RAM 
Dual CPU or Core (3.0 GHz or comparable chip) 
100 GB hard disk 


The hard disk should have ample space for logging in a production environment. This disk space 
must be in the local server and not in the remote server. 


Windows Server 2012 R2, 64-bit operating system (physical or virtual), in either Standard or 
Enterprise Edition, with the latest patches applied. 


Static IP address 
Ports 389 and 636 need to be free 


For information about browser support, see “Browser Support” on page 41. 


For information about network requirements, see Section 1.3, “Network Requirements,” on page 21. 


Installing the Administration Console 


2.2.2 Installation Procedure 


Installation time: about 20 minutes. 


What you need to create during installation A username and password for the Administrator. 


NOTE: If the Administration Console and the Identity Server are installed on different servers, both 
use 8080 and 8443 ports. If the Administration Console and the Identity Server are installed on the 
same server, Identity Server uses 8080 and 8443 ports and Administration Console uses 2080 and 
2443 ports. 


1 Verify that the machine meets the minimum requirements. See Section 2.2.1, “Installation 
Requirements on Windows,” on page 44. 


2 Close any running applications and disable any virus scanning programs. 
3 (Conditional) To use a remote desktop for installation, use any one of the following: 
+ Current version of VNC viewer 
+ Microsoft Remote Desktop with the /console switch for Windows XP SP2 
+ Microsoft Remote Desktop with the /admin switch for Windows XP SP3 
4 Download software and execute it. 
For software download instructions, see the release-specific Release Notes. 
5 Read the introduction, then click Next. 
6 Accept the license agreement, then click Next. 
7 Select Access Manager Administration Console, then click Next. 


If you are also installing the Identity Server on this machine, you can also select Access 
Manager Identity Server. 


8 Specify whether this is a primary Administration Console in a failover group, then click Next. 
The first Administration Console installed becomes the primary console. 


You can install up to three Administration Consoles for replication and failover purposes. If this is 
not the primary console, you must provide the IP address for the primary Administration 
Console. 


9 Specify an administration user ID and password. 


NOTE: If you are installing secondary Administration Console, the user ID must be from the 
o=novell container. If you specify a user from other container, the installer fails to install 
Administration Console. 


10 Specify the static IP address of the machine. 
11 Click Install. 
The configuration database takes awhile to install and configure. 
12 (Optional) After the installation completes, view the install log file found in the following location: 


Windows Server: \Program Files (x86)\Novell\log\AccessManagerServer_ 
InstallLog.log 


13 Restart the server. 
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IMPORTANT: You must restart the server before installing any other Access Manager 
components. 


14 Continue with “Configuring the Windows Administration Console Firewall” on page 46. 


2.2.2.1 Configuring the Windows Administration Console Firewall 


Before you can install other Access Manager components and import them into the Administration 
Console, or before you can log in to the Administration Console from a client machine, you must first 
configure the firewall on the Administration Console. 

1 Click Control Panel > Windows Firewall. 

2 Click Advanced, then for the Local Area Connection, click Settings. 

3 For each port that needs to be opened, click Add, then Specify the following details: 


Field Description 

Description of service Specify a name. For example, Admin Console 
Access for port 8080 or Secure Admin Console 
Access for port 8443. 

Name or IP address Specify the IP address of the Administration 
Console. 

External Port number for this service Specify the port. 


Open the following ports: 
+ 8080 
+ 8443 


4 (Conditional) If you are importing an Access Gateway into the Administration Console, add the 
following ports: 


+ 1443 
+ 8444 
+ 1289 
+ 1290 
+ 524 
+ 636 
For specific information about the ports listed in Step 3 and Step 4, see Table 1-3 on page 30. 


oa 


(Conditional) If you are importing an Access Gateway Appliance, click ICMP, select all options, 
then click OK twice. 


o 


Run the following commands to restart Tomcat: 


net stop Tomcat7 
net start Tomcat7 


7 Continue with Section 2.3, “Logging In to the Administration Console,” on page 47: 
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2.3 Logging In to the Administration Console 


IMPORTANT: The Administration Console is a combination of iManager and a device manager. It 
has been customized for Access Manager so that it can manage the Access Manager components. 


You cannot use it to log in to other eDirectory trees and manage them. 


You should not download and add iManager plug-ins to this customized version. It may result in 
destroying the Access Manager schema, which can prevent you from managing Access Manager 
components. This can also prevent communication among the modules. 


You should not start multiple sessions of the Administration Console on the same machine through 
the same browser. Browser shares session information and this can cause unpredictable issues in 
the Administration Console. You can, however, start different sessions with different brands of 
browsers. 


To log in to: 


1 Enable browser pop-ups. 
2 On the Administration Console, ensure that ports 8080 and 8443 are open. 


For information about how to do this, see “Configuring the Linux Administration Console 
Firewall” on page 43 and “Configuring the Windows Administration Console Firewall” on 
page 46. 

3 From a client machine external to your Administration Console server, launch browser and 
specify the Administration Console URL. 


Use the IP address established when you installed the Administration Console. It should include 
ports 8080 (HTTP) and 8443 (HTTPs) (if it is installed on a separate machine) and ports 2080 
(HTTP) and 2443 (HTTPs) (when Identity Server is installed on the same machine) and the 
application /nps. If the IP address of your Administration Console for example is 10.10.10.50, 
specify the following: 


http://10.10.10.50:8080/nps 
4 Click OK to accept the certificate. You can select either the permanent or temporary session 
certificate option. 


5 On the Login page, specify the administrator name and password that you defined during the 
Administration Console installation. 


6 Click Login. Access Manager Dashboard opens. 


For more information about this view or about configuring the Administration Console, see 
Configuring the Default View in the NetIQ Access Manager 4.3 Administration Guide. 


IMPORTANT: All configuration and management tasks in the Access Manager documentation 
assume that you know how to log in to the Administration Console. 


7 Continue with one of the following: 


+ Before you can configure the system, you need to install other Access Manager 
components. You need to install at least one Identity Server and one Access Gateway. It is 
recommended to next install the Identity Server. See Chapter 3, “Installing the Identity 
Servers,” on page 49. 


+ If your Administration Console server has multiple interface cards, see “Enabling the 
Administration Console for Multiple Network Interface Cards” on page 48. 
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NOTE: You can provide fault tolerance for the configuration store on the Administration Console by 
installing secondary versions of the console. See Section 1.6, “Installing Access Manager 
Components in NAT Environments,” on page 24. 


2.4 Enabling the Administration Console for Multiple 
Network Interface Cards 


Making the Administration Console available for all network interface cards (NICs) is a security risk. 
However, you might want to allow this situation if, for example, the Identity Server has multiple NICs 
and is also available on all ports. You must modify the server . xml file: 
1 Open the server.xml file, which is found in the following directory. 
Linux: /opt/novell/nam/adminconsole/conf 
Windows Server 2012 R2: \Program Files (x86)\Novell\Tomcat\conf 
2 Locate the connector with the NIDP_Name="connector" set. 
3 Delete the address attribute and save the file. 
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3.1 


Installing the Identity Servers 


Identity Server is the second component you install. You can install it on Linux or Windows. To 
authenticate to Identity Server through the User Portal page, use any of the following browsers: 


+ 


+ 


+ 


+ 


Firefox (41 and later) 

Chrome (45 and later) 

Edge (23.10565 with EdgeHTML 13.10565 and later) 
IE11 (11.0.9600 and later) 


This chapter explains how to install the Identity Server. Topics include: 


+ 


+ 


+ 


+ 


+ 


Section 3.1, “Prerequisites,” on page 49 

Section 3.2, “Installing the Identity Server on Linux,” on page 50 

Section 3.3, “Installing the Identity Server on Windows,” on page 52 
Section 3.4, “Verifying the Identity Server Installation,” on page 53 

Section 3.5, “Translating the Identity Server Configuration Port,” on page 54 


Prerequisites 


+ 


If you are installing Access Manager components on multiple machines, ensure that the time and 
date are synchronized on all machines. 


Ensure that the Administration Console is running. (See Chapter 2, “Installing the Administration 
Console,” on page 39.) 


Do not perform any configuration tasks in the Administration Console during an Identity Server 
installation. 


If you installed the Administration Console on a separate machine, ensure that the DNS names 
resolve between the Identity Server and the Administration Console. 


When you are installing the Identity Server on a separate machine (recommended for production 
environments), ensure that the following ports are open on both the Administration Console and 
the Identity Server: 


8444 

1443 

1289 

1290 

524 

636 

For information about how to open ports, see “Configuring the Linux Administration Console 


Firewall” on page 43 and “Configuring the Windows Administration Console Firewall” on 
page 46. 
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IMPORTANT: When you are installing the Identity Server on a machine with the Administration 
Console (not recommended for production environments), do not run simultaneous external 
installations of the Identity Server and Access Gateway. These installations communicate with 
the Administration Console. During installation, Tomcat is restarted, which can disrupt the 
component import process. 


¢ Verify that the machine meets the minimum requirements. See Section 3.2.1, “Installation 
Requirements on Linux,” on page 50. 


e You must establish a static IP address for your Identity Server to reliably connect with other 
Access Manager components. If the IP address changes, the Identity Server can no longer 
communicate with the Administration Console. 


3.2 Installing the Identity Server on Linux 


¢ Section 3.2.1, “Installation Requirements on Linux,” on page 50 


¢ Section 3.2.2, “Installation Procedure,” on page 51 


3.2.1 Installation Requirements on Linux 


+ 4 GB RAM 
¢ Dual CPU or Core (3.0 GHz or comparable chip) 
+ 100 GB hard disk 


This amount is recommended to ensure ample space for logging in a production environment. 
This disk space must be local and not remote. 


+ One of the following operating systems: 


+ SUSE Linux Enterprise Server (SLES) 11 SP4 and SLES 12 SP1 with 64-bit operating 
system x86-64 hardware. (physical or virtual). Ensure that the following packages are 
installed: 


¢ rsyslog-module-gtls 
+ rsyslog 
+ binutils 


+ Red Hat Enterprise Linux (RHEL) 6.8 and 7.2 (64-bit) (physical or virtual). For installing the 
RHEL packages, see Appendix 6, “Installing Packages and Dependent RPMs on RHEL for 
Access Manager,” on page 85. 


+ (Conditional) For Access Manager 4.3 Service Pack 3 (4.3.3), installation is also supported 
on RHEL 7.4 and SLES 12 SP3. 


+ gettext 
¢ python (interpreter) 
¢ Static IP address. 


IMPORTANT: 


+ No LDAP software, such as eDirectory or OpenLDAP, can be installed. (A default installation of 
SLES installs and enables OpenLDAP.) 


+ Because of library update conflicts, you cannot install Access Manager on a Linux User 
Management (LUM) machine. 
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For information about network requirements, see Section 1.3, “Network Requirements,” on page 21. 


3.2.2 Installation Procedure 


Installation time: about 10 minutes. 


What you need to know to + Username and password of the administrator. 


ineca e dena aei + (Conditional) IP address of the Administration Console if it is installed on a 


separate machine. 


1 Open a terminal window. 
2 Log in to as a root user. 
3 Access the install script. 
3a Ensure that you have downloaded the software or that you have the CD available. 
For software download instructions, see the release-specific Readme. 
3b Do one of the following: 


¢ Ifyou are installing from CD or DVD, insert the disc into the drive, then navigate to the 
device. The location might be /media/cdrom, /media/cdrecorder, or /media/ 
dvdrecorder, depending on your hardware. 


¢ If you downloaded the tar.gz file, unzip the file by using the following command: 
tar -xzvf <filename> 
3c Change to the novell-access-manager directory. 
4 At the command prompt, run the following install script: 


./install.sh 


5 When you are prompted to install a product, specify 2, Install Identity Server, then press Enter. 


This selection is also used for installing additional Identity Servers for clustering behind an L4 
switch. You need to run this install for each Identity Server you add to the cluster. 


NOTE: The Administration Console is accessible on ports 2080 (HTTP) and 2443 (HTTPs) if the 
Identity Server is installed on the same machine. 


The following warning is displayed: 


Warning: If NAT is present between this machine and Administration Console, 
configure NAT in the Administration Console. 

Exit this installation if NAT is not configured in the Administration Console. 
Would you like to continue (y/n)? 


For more information about how to configure NAT, see “Configuring the Administration Console 
Behind NAT” on page 28. 


6 Specify Y to proceed. 
7 Review and accept the License Agreement. 


8 Specify the IP address, user ID, and password for of the primary Administration Console. Specify 
the local NAT IP address if local NAT is available for the Identity Server. 


If the installation program rejects the credentials and IP address, ensure that the correct ports 
are open on both the Administration Console and the Identity Server, as described in 
Section 3.1, “Prerequisites,” on page 49. 
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9 The following components are installed: 


10 


Component Description 

Access Manager Server Enables network communications, including identifying devices, finding 
Communication services, moving data packets, and maintaining data integrity. 

Identity Server Provides authentication and identity services for the other Access 


Manager components and third-party service providers. 


Identity Server Configuration Allows the Identity Server to be securely configured by the Administration 
Console. 


If the installation process terminates at this step, the probable cause is a 
failure to communicate with the Administration Console. Ensure that you 
specified the correct IP address. 


Access Manager Server Enables the Identity Server to auto-import itself into the Administration 
Communications Console. 
Configuration 


Continue with one of the following: 
¢ Verify the installation. See “Verifying the Identity Server Installation” on page 53 


¢ Install an Access Gateway. See Section 4.2.2, “Installing the Access Gateway Appliance,” 
on page 61 or Section 4.3, “Installing the Access Gateway Service,” on page 64. 


+ Configure the Identity Server. See Setting Up a Basic Access Manager Configuration in the 
NetIQ Access Manager 4.3 Administration Guide. 


NOTE: After you install an Identity Server, you must create a cluster configuration. See Identity 
Servers Cluster in the NetIQ Access Manager 4.3 Administration Guide. 


3.3 Installing the Identity Server on Windows 


+ 


+ 


Section 3.3.1, “Installation Requirements on Windows,” on page 52 


Section 3.3.2, “Installation Procedure,” on page 53 


3.3.1 Installation Requirements on Windows 


+ 


+ 


+ 


4 GB RAM 
Dual CPU or Core (3.0 Ghz or comparable chip) 
100 GB hard disk 


This amount is recommended to ensure ample space for logging in a production environment. 
This disk space must be local and not remote. 


Windows Server 2012 R2 (physical or virtual), 64-bit operating system, in either Standard or 
Enterprise Edition, with the latest patches applied 


Static IP address 


IMPORTANT: No LDAP software, such as eDirectory or OpenLDAP, can be installed. (A default 
installation of SLES installs and enables OpenLDAP) 


Installing the Identity Servers 


3.3.2 


For information about network requirements, see Section 1.3, “Network Requirements,” on page 21. 


Installation Procedure 


Installation time: about 10 minutes. 


What you need to know to + Username and password of the administrator. 


install the Identity Server 


N O 


+ (Conditional) IP address of the Administration Console if it is installed on a 
separate machine. 


Verify that the machine meets the minimum requirements. See Section 3.3.1, “Installation 
Requirements on Windows,” on page 52. 


Ensure that you have read and implemented prerequisites specified in Section 3.1, 
“Prerequisites,” on page 49. 


Close any running applications and disable any virus scanning programs. 


(Conditional) If you have installed the Administration Console on this server, ensure that you 
have restarted the server before installing the Identity Server. 


Download software and run it. 

For software download instructions, see the release-specific Readme. 
Read the introduction, then click Next. 

Accept the license agreement, then click Next. 

Select Access Manager Identity Provider, then click Next. 


A warning is displayed: If NAT is present between this machine and Administration 
Console, the NAT configuration needs to be done in Administration Console. 


8 Specify the IP address, user ID, and password for the primary Administration Console. 


11 


12 


(Optional) Specify the Identity Server Local NAT IP address, if the device is behind NAT. 
Click Next, review the summary, and click Install. 


(Conditional) If you are installing the Identity Server on a machine that contains a previous 
installation of the Administration Console, you are asked whether the program should overwrite 
an existing file in the \Program Files\Novell directory. Specify yes. 


Continue with one of the following: 
¢ Verify the installation. See “Verifying the Identity Server Installation” on page 53 


¢ Install an Access Gateway. See Section 4.2.2, “Installing the Access Gateway Appliance,” 
on page 61 or Section 4.3, “Installing the Access Gateway Service,” on page 64. 


¢ Configure the Identity Server. See Configuring an Identity Server in the NetIQ Access 
Manager 4.3 Administration Guide. 


NOTE: After you install an Identity Server, you must create a cluster configuration. See Identity 
Servers Cluster in the NetIQ Access Manager 4.3 Administration Guide. 


3.4 Verifying the Identity Server Installation 


1 


Log in to the Administration Console. 
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3.5 


3.5.1 


3.5.2 


See Section 2.3, “Logging In to the Administration Console,” on page 47. 
2 Click Devices > Identity Servers. 


Translating the Identity Server Configuration Port 


If your Identity Server must communicate through a firewall, you must either set up a hole in your 
firewall for TCP ports 8080 or 8443 (default ports used respectively for non secure and secure 
communication with Identity Server), or configure the Identity Server service to use TCP port 80 or 
443. 

¢ “Changing the Port on a Windows Identity Server” on page 54 


¢ “Changing the Port on a Linux Identity Server” on page 54 


Changing the Port on a Windows Identity Server 


On a Windows Identity Server, you need to set the port in the Base URL and save the changes. You 
then need to modify the server.xml file located in the Tomcat configuration directory: 


1 In the Administration Console, click Devices > Identity Server > Edit, and configure the base 
URL with HTTPS as the protocol, and the TCP port as 443. 

2 Click OK, then update the Identity Server. 

3 In a terminal window, open the server.xml file. 
Windows Server 2012 R2: \Program Files (x86)\Novell\Tomcat\conf 

4 Change the ports from 8080 and 8443 to 80 and 443. 

5 Restart the Tomcat service. 
net stop Tomcat7 


net start Tomcat? 


Changing the Port on a Linux Identity Server 


On a Linux Identity Server, the Identity Server service (hosted on Tomcat) runs as a non-privileged 
user on Linux and cannot therefore bind to ports below 1024. In order to allow requests to port 80/443 
while Tomcat is listening on 8080/8443, the preferred approach is to use iptables to perform a port 
translation. Port translation allows the base URL of the Identity Server to be configured for port 443 
and to listen on this port, and the iptables translates it to port 8443 when communicating with Tomcat. 


¢ If you have disabled the SUSE Linux Enterprise Server (SLES) firewall and do not have any 
other Access Manager components installed on the Identity Server, you can use a simple 
iptables script to translate the ports. See “A Simple Redirect Script” on page 55. 


¢ If you have configured the SLES firewall or have installed other Access Manager components on 
the Identity Server, you use a custom rule script that allows for multiple port translations. See 
“Configuring iptables for Multiple Components” on page 56. 


These sections describe two solutions out of many possibilities. For more information about iptables, 
see the following: 


+ “Iptable Tutorial 1.2.2” 
+ “NAM Filters for iptables Commands” 
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A Simple Redirect Script 


This simple solution works only if you are not using iptables to translate ports of other applications or 
Access Manager components. For a solution that works with multiple components, see “Configuring 
iptables for Multiple Components” on page 56. 


1 In the Administration Console, click Devices > Identity Server > Edit, and configure the base 
URL with HTTPS as the protocol, and the TCP Port as 443. 


2 Click OK, then update the Identity Server. 
3 Ata terminal window, log in as the root user. 
4 Create a file to hold the iptables rule and place it in the /etc/init .d directory. 


For example, /etc/init .d/AM_IDP_Redirect. Ensure it has execute rights. You can use 
CHMOD as appropriate. 


An example of a redirect startup file for this purpose might be: 


#!/bin/sh 

# Copyright (c) 2010 Novell, Inc. 
# All rights reserved. 

# 

#! /bin/sh 

#! /etc/init.d/idp_8443 redirect 
### BEGIN INIT INFO 

Provides: idp_8443_redirect 
Required-Start: 

Required-Stop: 

Default-Start: 235 
Default-Stop: 0 1 6 
Description: Redirect 8443 to 443 for Novell IDP 
### END INIT INFO # 


+ EHHH 


# Environment-specific variables. 
IPT_BIN=/usr/sbin/iptables 
INTF=eth0 

ADDR=10.10.0.1 


. /etc/rc.status 


# First reset status of this service 
rc_reset 


case "$1" in 
start) 

echo -n "Starting IP Port redirection" 

$IPT_BIN -t nat --flush 

$IPT_BIN -t nat -A PREROUTING -i $INTF -p tcp --dport 80 -j DNAT --to 
${ADDR} : 8080 

$IPT_BIN -t nat -A PREROUTING -i $INTF -p tcp --dport 443 -j DNAT --to 
${ADDR} : 8443 

$IPT_BIN -t nat -A OUTPUT -p tcp -d $ADDR --dport 443 -j DNAT --to 
${ADDR} : 8443 

$IPT_BIN -t nat -A OUTPUT -p tcp -d $ADDR --dport 80 -j DNAT --to 
${ADDR} : 8080 

rc_status -v 

v7 


stop) 
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echo -n "Flushing all IP Port redirection rules" 
$IPT_BIN -t nat --flush 
rc_status -v 


tr 
restart) 
$0 stop 
$0 start 
rce_status 
it 
*) 
echo "Usage: $0 {start|stop|restart}" 
exit 1 
it 
esac 
rc_exit 


For more information about init scripts for SUSE Linux Enterprise Server 11, see “Section 7.2.2 
Init Scripts” in the SLES 11 Administration Guide. 


Modify the environment-specific variables found in the following lines: 


# Environment-specific variables. 
IPT_BIN=/usr/sbin/iptables 
INTF=ethO 

ADDR=10.10.0.1 


To ensure that the iptables rule is active after rebooting, start YaST, click System, > System 
Services (Runlevel), select Expert Mode, select the file you created, enable runlevels boot, 3 
and 5 for the file, then start the service. 


To verify that your script is running, enter the following command: 


ls /etc/init.d/rc3.d | grep -i AM_IDP_Redirect 


8 Reboot the Identity Server machine. 


9 


10 


After rebooting, verify that port 443 is being routed to the Identity Server by entering the following 
command: 


iptables -t nat -nvL 
You should see an entry similar to the following: 


pkts bytes target prot opt in out source destination 
17 748 DNAT tcp -- etho * 0.0.0.0/0 0.0.0.0/0 
tcp dpt:443 to:10.10.0.1:8443 


This entry states that ethO is routing TCP port 443 to IP address 10.10.0.1. 


(Conditional) If your Identity Server cluster configuration contains more than one Identity Server, 
repeat these steps on each server in the cluster. 


Configuring iptables for Multiple Components 


If you need to use iptables for multiple components (the host machine, the Identity Server), you need 
to centralize the commands into one manageable location. The following sections explain how to use 
the SuSEFirewall2 option in YaST to centralize the commands. 


The Identity Server uses requires pre-routing commands. 
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Adding the Identity Server Commands 
1 In the Administration Console, click Devices > Identity Server > Edit, and configure the base 
URL with HTTPS as the protocol, and the TCP port as 443. 
2 Click OK, then update the Identity Server. 
3 On the Identity Server, edit the /etc/sysconfig/SuSEfirewal12 file. 
3a Change the FW_CUSTOMRULES="" line to the following: 
FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom" 
3b Save the changes and exit. 
4 Open the /etc/sysconfig/scripts/SuSEfirewall2-custonm file in an editor. 
This is the custom rules file you specified in Step 3. 
5 Add the following lines under the fw_custom_before_port_handling() section: 


iptables -t nat -A PREROUTING -i eth® -p tcp --dport 443 -j DNAT --to 
10.10.0.1:8443 

iptables -t nat -A OUTPUT -p tcp -o ethO --dport 443 -j DNAT --to 
10.10.0.1:8443 

true 


The first command rewrites all incoming requests with a destination TCP port of 443 to TCP port 
8443 on the 10.10.0.1 IP address for ethO. Modify the IP address to match the IP address of your 
Identity Server. 


The second command rewrites the health checks. 
6 Save the file. 
7 Atthe system console, restart the firewall by executing the following command: 


/etc/init .d/SuSEfirewall2_setup restart 


8 After rebooting, verify that port 443 is being routed to the Identity Server by entering the following 
command: 


iptables -t nat -nvL 
You should see an entry similar to the following: 


pkts bytes target prot opt in out source destination 
17 748 DNAT tcp -- etho * 0.0.0.0/0 0.0.0.0/0 
tcp dpt:443 to:10.10.0.1:8443 


This entry states that ethO is routing TCP port 443 to IP address 10.10.0.1:8443. 


9 (Conditional) If your Identity Server cluster configuration contains more than one Identity Server, 
repeat these steps on each server in the cluster. 
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4.1 


Installing the Access Gateway 


You can install the Access Gateway in one of the following two modes: 


+ Appliance: Operating system is installed with the Access Gateway software. 

¢ Service: The Access Gateway installed on a machine with an existing operating system. 
This chapter explains the difference between Access Gateway Appliance and Access Gateway 
Service and how to install the Access Gateway. Topics include: 

¢ Section 4.1, “Feature Comparison of Different Types of Access Gateways,” on page 59 

e Section 4.2, “Installing the Access Gateway Appliance,” on page 60 

¢ Section 4.3, “Installing the Access Gateway Service,” on page 64 


¢ Section 4.4, “Verifying the Access Gateway Installation,” on page 68 


Feature Comparison of Different Types of Access 
Gateways 


Access Manager includes the Access Gateway Appliance and Access Gateway Service. The Access 
Gateway Appliance installs its own embedded Linux operating system. Whereas, the Access 
Gateway Service runs on top of an existing installation of a Linux or Windows operating system. Both 
types of gateways support similar functionalities, but they differ slightly in the way some of these 
features are supported. For example, both can be configured for the following features: 


¢ Protecting Web resources with contracts, Authorization, Form Fill, and Identity Injection policies. 
¢ Providing fault tolerance by clustering multiple gateways of the same type. 


¢ Providing fault tolerance by grouping multiple Web servers, so that if one Web server goes 
down, the content can be retrieved from another server in the group. 


¢ Rewriting URLs so that the names and IP addresses of the Web servers are hidden from the 
users making requests. 


¢ Generating alert, audit, and logging events with notify options. 


Most differences between Access Gateway Appliance and Access Gateway Service result from the 
differences required for an appliance and for a service. An appliance can know, control, and configure 
many features of the operating system. A service that runs on top of an operating system can query 
the operating system for some information, but it cannot configure or control the operating system. 
For the service, operating system utilities must be used to configure system parameters and 
hardware. For the appliance, the operating system features that are important to the appliance, such 
as time, DNS servers, gateways, and network interface cards, can be configured in the Administration 
Console. 


This table describes the differences between Access Gateway Appliance and Access Gateway 
Service. Only your network and Web server configurations can determine whether the differences are 
significant. 


Installing the Access Gateway 59 


Table 4-1 Differences between Access Gateway Appliance and Access Gateway Service: 


Feature Access Gateway Appliance Access Gateway Service 


Platform support SLES 11 SP4 only + SLES 11 SP4 
+ SLES 12 SP1 
+ Red Hat Enterprise Linux 6.8 
+ Red Hat Enterprise Linux 7.2 
+ Windows 2012 R2 


Network configuration Configurable from the Administration Configurable with standard 
Console. operating system utilities. 
+ DNS servers 
By default after the installation, only one 


* Gateways network interface card will be displayed in 


+ Network interface the Administration Console. To detect other 
cards network interface card, do the following: 
* Host names ¢ Configure a primary IP Address in 


YaST for the remaining interfaces. 


+ Click Devices > Access Gateways > 
Select the device > New IP > click 


OK. 
Date and time Configurable from the Administration Configurable with standard 
Console. operating system utilities. 
Cache directory Uses Apache-caching. The cached files are Uses filesystem provided by 


stored in clear text. The operating system Apache mod_cache module. 


must be configured to protect this directory. 
For more information about the 


For more information about the Apache Apache model, see “Caching 
model, see “Caching Guide”. Guide”. 


4.2 Installing the Access Gateway Appliance 


¢ Section 4.2.1, “Access Gateway Appliance Requirements,” on page 60 
¢ Section 4.2.2, “Installing the Access Gateway Appliance,” on page 61 


4.2.1 Access Gateway Appliance Requirements 


The Access Gateway Appliance runs 64bit operating system on x86-64 hardware supported by SLES 
11 SP4. Install it on a separate server because it clears the hard drive and sets up a soft appliance 
environment. 


The Access Gateway Appliance requires the following hardware: 


+ 4 GB RAM 
¢ Dual CPU or Core (3.0 GHz or comparable chip) 
+ 100 GB hard disk 
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4.2.2.1 


The hard disk should have ample space for logging in a production environment. This disk space 
must be local and not remote. 


+ Astatic IP address for your Access Gateway server and an assigned DNS name (host name and 
domain name). 
For information about network requirements, see Section 1.3, “Network Requirements,” on page 21. 


For a list of hardware that SLES 11 SP4 for x86-64 hardware supports, open YES CERTIFIED 
Bulletin (http://developer.novell.com/yessearch/Search.jsp), select Service Pack 4 for SUSE® SLES 
11 in NetIQ Product, and search for your other hardware requirements. 


The Access Gateway Appliance has no software requirements. The installation program re-images 
the hard drive, embeds the Linux operating system, then configures the embedded operating system 
for optimal performance. 
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Installation time: 15 to 30 minutes, depending upon the hardware. 


What you need to know + Username and password of the administrator. 
+ IP address of the Administration Console. 
+ Static IP address for the Access Gateway. 


+ DNS name (host and domain name) for the Access Gateway that resolves 
to the IP address. 


+ Subnet mask that corresponds to the IP address for the Access Gateway. 
+ IP address of your network’s default gateway. 
+ IP addresses of the DNS servers on your network. 


+ IP address or DNS name of an NTP server. 


The Access Gateway Appliance can be installed on all supported hardware platforms for SUSE Linux 
Enterprise Server (SLES) 11 SP4 or a higher version. 


IMPORTANT: After the Access Gateway Appliance installation, upgrade the Linux kernel to the latest 
security patch to avoid any security vulnerabilities. For more information, see Chapter 11, “Getting the 
Latest Security Patches,” on page 121. 


This section provides the following information about how to install the Access Gateway Appliance: 
¢ Section 4.2.2.1, “Prerequisites,” on page 61 
¢ Section 4.2.2.2, “Installing the Access Gateway Appliance,” on page 62 
¢ Section 4.2.2.3, “Creating Custom Partitions,” on page 63 


Prerequisites 


+ Ensure that you have backed up all data and software on the disk to another machine. The 
Access Gateway Appliance installation completely erases all the data on your hard disk. 
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+ Ensure that the server meets the minimum hardware requirements. See Section 4.2.1, “Access 
Gateway Appliance Requirements,” on page 60. 


+ (Optional) If you want to try any advanced installation options such as driver installation or 
network installation, see the SUSE Linux Enterprise Server 11 Installation Guide (https:// 
www.suse.com/documentation/sles11/book_sle_deployment/data/book_sle_deployment.html). 


4.2.2.2 Installing the Access Gateway Appliance 


1 Insert the Access Gateway Appliance CD into the CD drive and boot from CD. The boot screen 
appears. 


2 By default, the Boot From Hard Disk option is selected. Use the Down-arrow key to select Install 
Appliance. 


Press Enter. 
Review the agreement on the License Agreement page, then click | Agree. 
Select the region and time zone on the Clock and Time Zone page. 


ao a Aa Q 


(Conditional) If the date and time are not the same as the date and time on the Administration 
Console, click Change, adjust the date and time. 


7 Click Next. 
8 Configure the following details on the Appliance Configuration page: 


Field Description 


Host Name The hostname of the Access Gateway Appliance server. 


IMPORTANT: Do not use linux as hostname. If you do, the 
Access Gateway is not imported 


Domain Name The domain name for your network. 

IP Address The IP address of the Access Gateway. 

Subnet Mask The subnet mask of the Access Gateway Appliance network. 
Default Gateway The IP address of the default gateway. 

DNS Server The IP address of your DNS server. You must configure at least 


one DNS server. 


Specify the IP address of additional your additional DNS server, if 
you have configured. This is an optional configuration. 


In the Root Password section, specify password. 
In the NTP Server Configuration section, specify the name of the NTP server. 


In the NAT Settings section, specify the Access Gateway Local NAT IP Address, if the device is 
behind NAT. 


In the Administration Console configuration section, specify the following: 


IP Address The IP address of the Administration Console. The Access 
Gateway Appliance is imported into this Administration Console. 


Username The name of the Administration Console user. 


Password Specify the password for the user. 
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9 Click Next. The Installation Settings page appears. 
This page displays the options and software you selected in the previous steps. Use the 


Overview tab for a list of selected options, or use the Expert tab for more details. Ensure that all 


default partitions recommended adhere to the guidelines mentioned in Table 4-2 on page 63. 


NOTE: Do not change the software selections listed on this screen. 

10 (Optional) To modify the installation settings for partitions, click Change. For more information 
about partitions, see Section 4.2.2.3, “Creating Custom Partitions,” on page 63. 

11 Click Install > Install. 
This process might take 15 to 30 minutes, depending on the configuration and hardware. 


The machine reboots after the installation is completed. It runs an auto import script, and then 
the Access Gateway Appliance is imported to the Administration Console. 


12 Continue with one of the following sections: 
¢ Verify the installation. See “Verifying the Access Gateway Installation” on page 68 
¢ Configure the Access Gateway. See Configuring Access Gateway in the NetlQ Access 
Manager 4.3 Administration Guide. 
The Access Gateway Appliance is installed with the following default partitions: 


¢ boot: The size is automatically calculated and the mount point is /boot. 
+ swap: The size is double of the size of RAM and the mount point is swap. 


The remaining disk space after the creation of the /boot and swap partitions is allocated as the 
extended drive. The extended drive has the following partitions: 


+ root: The default size is one-third the size of the extended drive and the mount point is /. 
¢ var: The default size is one-third the size of the extended drive and the mount point is /var. 


The Access Gateway Appliance does not support configuring multiple network interfaces during 
installation. The ethO interface is configured by default. If you require multiple interfaces, you can 
configure them through the Administration Console after installation. 


Creating Custom Partitions 


Linux allows you to have four primary partitions per hard disk. The Access Gateway Appliance 
requires a swap partition, a var partition, and a root partition. For a machine with a large hard disk 
(100 GB or larger), we recommend creating the following partitions: 


Table 4-2 Access Gateway Appliance Partitions 


Partition Type Requirements 


root This partition contains the boot files, system files, and log files. You should assign 40% of 


available disk space to this partition. This space should be more than 40 GB. 
swap Create a swap partition that is twice the size of RAM installed on the machine. 


var This partition is used for log files and caching objects of the Access Gateway. Allocate the 
remaining space for this partition, which should be more than 50 GB. Assign the 
remaining disk space to var. 
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To create your custom partitions: 
1 Inthe Installation Settings page, click Change, then select Partitioning. (See Step 10 on 
page 63.) 
This page lists the partition settings as currently proposed. 
2 Select Custom partitioning, then click Next. 


3 (Conditional) If the installation program discovers any existing partitions, select the hard disk, 
click Delete, then confirm the deletion of the partitions. 


4 Create a root partition as follows: 
4a Click Add, select the primary or extended partition, then click OK. 
4b Specify the following details: 
Format: Ensure that Format is selected. 
You must format the partition after you have modified the partition size during installation. 
File system: Select Ext3 for the type. 
Custom Size: Specify a value. 
Mount Point: Select /. 
4c Click Finish. 
5 Create a swap partition as follows: 
5a Select the hard drive, click Create, select the primary or extended partition, then click OK. 
5b Specify the following details: 
Format: Ensure that Format is selected. 
File system: Select Swap for the type. 
Custom Size: Specify a value. 
Mount Point: Leave the default value of swap. 
5c Click Finish. 
6 Create a var partition as follows: 
6a Select the hard drive, click Add, select the primary or extended partition, then click OK. 
6b Specify the following details: 
Format: Ensure that Format is selected. 
File system: Select Ext3 for the type. 
Custom Size: Specify a value. 
Mount Point: Select /var. 
6c Click Finish. 
7 Click Accept to create partitions with the specified values. 


8 In the installation Summary page, verify that the partitions you specified are listed, then continue 
with Step 11 on page 63. 


4.3 Installing the Access Gateway Service 


¢ Section 4.3.1, “Installing the Access Gateway Service on Linux,” on page 65 


¢ Section 4.3.2, “Installing the Access Gateway Service on Windows,” on page 67 
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Installing the Access Gateway Service on Linux 


IMPORTANT: Because of library update conflicts, you cannot install Access Manager on a Linux 
User Management machine. 


¢ Section 4.3.1.1, “Linux Requirements,” on page 65 
¢ Section 4.3.1.2, “Prerequisites,” on page 66 


¢ Section 4.3.1.3, “Installation Procedure,” on page 66 


Linux Requirements 


+ One of the following operating systems: 


+ SUSE Linux Enterprise Server (SLES) 11 SP4 and SLES 12 SP1 (64-bit) (physical or 
virtual). 


+ Red Hat Enterprise Linux (RHEL) 6.8 (64-bit) (physical or virtual) and 7.2 (64-bit) (physical 
or virtual) 


+ (Conditional) For Access Manager 4.3 Service Pack 3 (4.3.3), installation is also supported 
on RHEL 7.4 and SLES 12 SP3. 


+ 4 GB RAM. 
¢ Dual CPU or Core (3.0 GHz or comparable chip). 


+ 2to10 GB hard disk space per reverse proxy that requires caching and for log files. The amount 
varies with rollover options and logging level that you configure. 


+ Astatic IP address and a DNS name. The ActiveMQ module of the Access Gateway Service 
must be able to resolve the machine’s IP address to a DNS name. If the module can’t resolve the 
IP address, the module does not start. 


+ Other Access Manager components should not be installed on the same machine. 


¢ For installing the RHEL packages, see Appendix 6, “Installing Packages and Dependent RPMs 
on RHEL for Access Manager,” on page 85. 


+ (Only for SLES) Ensure that the following rpms or higher versions are installed: 
¢ rsyslog-module-gtls-5.10.1-0.7.49 
+ rsyslog-5.10.1-0.7.49 
¢ binutils 2.23.1-0.17.18 


IMPORTANT 


¢ SLES installation libraries may be distributed across multiple CDs or DVDs. In YaST > 
Software > Software Repositories select the required CD or DVD to install the rpm files. If 
the rpm files are not available on the SLES server, the Access Manager installation process 
takes care of installing these rpm files from the SLES repository. 


+ To search if an rpm is installed, use rpm -qa | grep <rfpmname>. For example, rpm - ga 
| grep libapr-util. 


For information about network requirements, see Section 1.3, “Network Requirements,” on page 21. 
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4.3.1.2 Prerequisites 


+ An Administration Console must be installed before you install the Access Gateway Service. See 
Section 2, “Installing the Administration Console,” on page 39. 


+ An Identity Server must be installed and configured before installing the Access Gateway 
Service. See, Section 3, “Installing the Identity Servers,” on page 49. 


¢ Verify that the server meets the minimum requirements. See Section 4.3.1, “Installing the Access 
Gateway Service on Linux,” on page 65. 


¢ Verify that the time on the machine is synchronized with the time on the Administration Console. 
If the times differ, the Access Gateway Service does not import into the Administration Console. 


¢ Ifa firewall separates the machine and the Administration Console, ensure that the required 
ports are opened. See Table 1-3 on page 30. 


+ Because the Access Gateway Service is running as a service, the default ports (80 and 443), 
which the Access Gateway Service uses might conflict with the ports of other services running 
on the machine. If there is a conflict, you need to decide which ports each service can use. 


+ (Windows Server 2012) If the Web server (IIS) has been installed by default during the Windows 
Server 2012 install. The Access Gateway Service installation program detects its presence from 
the registry and issues a shutdown command. Even if you have never activated the Web server 
and if even it is not running, the shutdown command is issued. Because the Access Gateway 
Service cannot be installed while the IIS server is running, the installation program needs to 
ensure that it is not running. 


NOTE: The Access Gateway Service clustering is supported for devices that are on the same 
operating system. 


4.3.1.3 Installation Procedure 


66 


Installation time: about 10 minutes. 


What you need to know + Username and password of the administrator. 


+ IP address of the Administration Console. 


IMPORTANT: The Access Gateway Service must be installed on a separate machine. 


1 Log in to the NetlQ Customer Center and follow the link that allows you to download software. 
For an evaluation version, download the media kit from NetIQ Downloads. 


2 Copy the file to your machine. 
For the filename, see the NetIQ Access Manager Readme. 
3 Prepare your machine for installation: 
Make your operating system installation media available. 
The installation program checks for Apache dependencies and installs any missing packages. 
4 Start installation by running the following script: 
./ag_install.sh 
5 Review and accept the License Agreement. 
6 Specify the IP address, user ID, and password of the primary Administration Console. 
7 (Optional) Specify the local NAT IP address if the local NAT is available for the Access Gateway. 
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4.3.2.1 


4.3.2.2 


8 Continue with one of the following sections: 


¢ Verify the installation. See “Verifying the Access Gateway Installation” on page 68 


+ Configure the Access Gateway. See Configuring Access Gateway in the NetIQ Access 
Manager 4.3 Administration Guide. 


Installing the Access Gateway Service on Windows 


+ 


+ 


Section 4.3.2.1, “Windows Requirements,” on page 67 


Section 4.3.2.2, “Installation Procedure,” on page 67 


Windows Requirements 


+ 


+ 


Windows Server 2012 R2, 64-bit operating system in Standard Edition with the latest patches 
applied (physical or virtual) 


4 GB RAM 
Dual CPU or Core (3.0 GHz or comparable chip) 


2 to10 GB per reverse proxy that requires caching and for log files. The amount varies with 
rollover options and logging level that you configure 


A static IP address and a DNS name. The ActiveMQ module of the Access Gateway Service 
must be able to resolve the machine’s IP address to a DNS name. If the module cant resolve the 
IP address, the module does not start. 


You can verify this by using the nslookup command. Enter this command with hostname in the 
command prompt and it should return the IP address of the host 


Other Access Manager components should not be installed on the same machine 


For information about network requirements, see Section 1.3, “Network Requirements,” on page 21. 


For prerequisites, see “Prerequisites” on page 61. 


Installation Procedure 


Installation time: about 10 minutes. 


What you need to know + Username and password of the administrator. 


+ |P address of the Administration Console. 


IMPORTANT: The Access Gateway Service must be installed on a separate server. 


1 


Log in to the NetIQ Customer Center (http://www.novell.com/center) and follow the link that 
allows you to download software. For an evaluation version, download the media kit from NetIQ 
Downloads (https://dl.netiq.com/index.jsp). 


Copy the file to your machine. 
For the filename, see the release-specific NetIQ Access Manager Readme. 


3 Disable any virus scanning programs. 


To use a remote desktop for installation, use one of the following: 
+ Current version of VNC viewer 
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10 
11 
12 


13 
14 
15 


16 
17 


18 


+ Microsoft Remote Desktop with the /console switch for Windows XP SP2 
+ Microsoft Remote Desktop with the /admin switch for Windows XP SP3 
Double click the executable file. 


A warning is displayed stating If NAT is present between console, the NAT 
configuration needs to be done in Administration Console. 


If NAT is configured then ensure that you configure the same in the Administration Console. 
Else, click Continue >Next. 


Review the readme, and click Next. 
Review and accept the License Agreement, then click Next. 
Specify the IP address, user ID, and password of the primary Administration Console. 


(Conditional) Specify the local IP address, if your machine has more than one IP address, which 
the Access Gateway Service will use for communication with the Administration Console. 


(Optional) Specify the Access Gateway Local NAT IP address, if the device is behind NAT. 
Click Next. 
Configure disk cache. This holds the caching objects of the Access Gateway. 


NOTE: The Access Gateway Appliance uses the mod_cache module filesystem provided by 
Apache for storing the caching objects. If you want to change the size of this cache after 
installation, see TID on Changing the Cache Size of an Access Gateway Appliance after 
Installation. 


Click Next, then review the installation summary. 
Click Install. 
Review the log information at the following location: 


C:\Program Files\Novell\log 


Click Next > Done. 


To verify that the Access Gateway Service imported into the Administration Console, wait for few 
minutes, log in to the Administration Console, then click Devices > Access Gateways. 


At this point, the Access Gateway Service is not configured. 
Continue with one of the following: 
+ “Verifying the Access Gateway Installation” on page 68 


+ Configure the Access Gateway. See Configuring Access Gateway in the NetIQ Access 
Manager 4.3 Administration Guide. 


¢ Install another Access Manager component. 


4.4 Verifying the Access Gateway Installation 


1 


2 


Log in to the Administration Console. 
See Section 2.3, “Logging In to the Administration Console,” on page 47. 
Click Devices > Access Gateways. 


If the installation was successful, the IP address of your Access Gateway appears in the Server 
list. 


The Health status indicates the health state after the Access Gateway is imported and registers 
with the Administration Console. 
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NOTE: The Access Gateway Appliance health is displayed as green instead of yellow, even 
before a trust relationship is established between an Embedded Service Provider and the 
Access Gateway. You must establish a trust relationship with the Identity Server before you 
proceed with any other configuration. 


If an Access Gateway starts to import into the Administration Console but fails to complete the 
process, the following message appears: 


Server gateway-<name> is currently importing. If it has been several minutes 
after installation, click repair import to fix it. 


If you have waited at least ten minutes, but the message doesn’t disappear and the Access 
Gateway does not appear in the list, click the repair import link. 
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Installing Analytics Server 


You can install Analytics Server after installing Administration Console. You can install it on any 
server without the requirement for any base operating system because Analytics Server is packaged 
with SLES operating system. Before you install Analytics Server, review new functionality and known 
issues in the supported SLES Release Notes. 


Analytics Server is packaged in ISO format, which can be deployed to the virtual environments. 
This chapter includes the details on installing and deploying Analytics Server. 


¢ Section 5.1, “Installing Analytics Server,” on page 71 
¢ Section 5.2, “Post-Installation Configuration for Analytics Server,” on page 74 
¢ Section 5.3, “Deploying Analytics Server for High Availability,” on page 74 


5.1 Installing Analytics Server 


This section provides information about installing Analytics Server. This image format allows you to 
generate a full disk image format that can be deployed directly to hardware, either physical (bare 
metal) or virtual (uninstalled virtual machine in a hypervisor) by using a bootable ISO DVD image. 

¢ Section 5.1.1, “System Requirements,” on page 71 

¢ Section 5.1.2, “Installation Checklist,” on page 72 

¢ Section 5.1.3, “Installing Analytics Server,” on page 72 


¢ Section 5.1.4, “Adding And Configuring Multiple Network Interface Card to Analytics Server,” on 
page 74 


5.1.1 System Requirements 


Ensure that the environment where you are going to install this ISO, meets the following 
prerequisites: 


¢ (Conditional) If you are installing the ISO on bare metal hardware, download the ISO disk image 
from the support site, unpack the file, and make a DVD. 


+ Itis recommended to use 24 GB for production environment. However, the minimum memory of 
6.5 GB can be used for demonstration purpose. 


+ Ensure that the minimum hard disk space is 50 GB for the installer to make the automatic 
partition proposal. 


+ Ensure that you use (4 core) CPUs (8 cores total). 
5.1.1.1 System Requirements for Storing 500 Events Per Second (EPS) 


To store 500 EPS for an year, you require the following: 


¢ CPU: Two Intel(R) Xeon(R) CPU ES-2650 @ 2.00GHz (4 core) CPUs (8 cores total), no hyper- 
threading. 


+ Primary storage: 10 x 300 GB SAS 15k RPM (Hardware RAID 10) 
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5.1.2 


5.1.3 


+ 


Memory: 24 GB 


Installation Checklist 


Ensure that you have completed the following tasks before you start the installation: 


o 


o 


o 


Verify that your hardware and software meet the system requirements listed in Section 5.1.1, 
“System Requirements,” on page 71. 


If there was a previous installation of Analytics Server, ensure that there are no files or system 
settings remaining from a previous installation. 


Ensure that the ports listed in Section 1.7, “Setting Up Firewalls,” on page 29 are opened in the 
firewall. 


Installing Analytics Server 


To install Analytics Server perform the following: 


NOTE: If you plan to include multiple Network Interface Card (NIC), then you must install Analytics 
Server with one NIC and then proceed with configuring other network interfaces. For more 
information, see Section 5.1.4, “Adding And Configuring Multiple Network Interface Card to Analytics 
Server,” on page 74. 


1 Download the ISO for the Analytics Server image from the NetIQ Download Website. 


(Conditional) If you are using a hypervisor: 
Set up the virtual machine using the ISO virtual appliance image, and power it on. 
or 
Copy the ISO image into a DVD, set up the virtual machine using the DVD, and power it on. 
(Conditional) If you are installing the Analytics Server on bare metal hardware: 
3a Boot the physical machine from the DVD drive with the DVD. 
3b Follow the installation wizard on-screen instructions. 
3c Run the Live DVD appliance image by selecting the top entry in the boot menu. 


The installation checks for the available memory. If the available memory is less than 6.5 
GB, the installation will not proceed further. Enter y if you want to continue with the 
installation, or enter n if you do not want to proceed. 


4 Select the language of your choice and keyboard Configuration, then click Next. 


5 Read and accept the Access Manager Analytics Server End User License Agreement. Click 


Next 


On the Hostname and Domain Name page, specify the hostname and domain name. Deselect 
Assign Hostname to Loopback IP, then click Next. 


Choose one of the following connection settings options: 


+ To use the current network connection settings, select Use the following configuration on 
the Network Configuration II page. 


+ To change the network connection settings, click Change, then make the desired changes. 
Click Next. 
Set the Time and Date, then click Next. 
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To change the NTP configuration after installation, use YaST from the appliance command line. 
If the time appears out of sync immediately after the install, run the following command to restart 
NTP: 


rentp restart 


10 Set the root password, then click Next. 


11 In the Analytics Server Configuration screen, set the Analytics Server admin password, select 
Use IP address for event routing, then click Next. 


12 In the Administration console server Information screen, specify the following to import 
Analytics server to the specified Administration Console: 


IP Address: IP address of the Administration Console. 

Admin User: The name of the user accessing Administration Console. 
Password: Password of the Administration Console user. 

Confirm the password, then click Next. 


NOTE: If the password includes the “&” symbol, the installation fails. You must change the admin 
password in Administration Console (without “&”) to continue with Analytics server installation. 


13 The Live Installation Settings screen displays the selected installation settings. Review the 
settings, configure the settings (if necessary), and then select Install. 


14 Select Install to confirm the Installation. 


Wait until the installation finishes. It might take few minutes for all services to start up after 
installation because the system performs a one-time initialization. 


15 The Suggested Partitioning screen displays the recommended partition setup. Review the 
partition setup, configure the setup (if necessary), and then select Next. Modify these settings 
only if you are familiar with configuring partitions in SLES. 


You can configure the partition setup by using the various partitioning options on the screen. For 
more information about configuring partitions, see Using the YaST Partitioner in the SLES 
documentation. 


16 Select OK to reboot the system. 
17 (Conditional) If you are using a physical machine, eject the DVD. 
18 (Conditional) If you are using a hypervisor click Enter. 
19 Enter the root username and password at the console to log in to the appliance. 
The default value for the username is root and the password is the password you set in Step 10. 
20 Proceed with Section 5.2, “Post-Installation Configuration for Analytics Server,” on page 74. 


NOTE: For installing Analytics Server in high-availability mode, see Section 5.3.2, “Installing 
Analytics Server in High Availability Environment,” on page 75. 
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5.1.4 


5.2 


5.2.1 


5.3 


5.3.1 


Adding And Configuring Multiple Network Interface Card to 
Analytics Server 


If you want to install multiple Network Interface Card, and configure multiple IP addresses for 
Analytics Server, then perform the following: 


1 Install Analytics Server with one Network Interface Card that is configured with the IP address 
that must be used for communicating with Administration Console. For installation steps refer 
Section 5.1.3, “Installing Analytics Server,” on page 72. 


2 After the installation completes, configure the other required network interfaces by using YaST. 


Post-Installation Configuration for Analytics 
Server 


After you install Analytics Server, you need to perform additional configuration for it to work properly. 


Registering for Updates 


You must register Analytics Server with the server update channel to receive patch updates. For more 
information about registering the server, see Section 11.1.1, “Registering to Novell Customer Center,” 
on page 121. 


Deploying Analytics Server for High Availability 


This section provides information about how to install Analytics Server in an Active-Passive High 
Availability mode, which allows the server to fail over to a redundant cluster node in case of hardware 
or software failure. For more information on implementing high availability and disaster recovery in 
the Analytics Server environment, contact NetIQ Technical Support. 


High availability refers to a design methodology that is intended to keep a system available for use as 
much as is practicable. The intent is to minimize the causes of downtime such as system failures and 
maintenance, and to minimize the time it will take to detect and recover from downtime events that do 
occur. In practice, automated means of detecting and recovering from downtime events quickly 
become necessary as higher levels of availability must be achieved. 


For more information about high availability, see the SUSE High Availability Guide. 


¢ Section 5.3.1, “Prerequisite,” on page 74 
¢ Section 5.3.2, “Installing Analytics Server in High Availability Environment,” on page 75 


¢ Section 5.3.3, “Post-Installation Cluster Configuration for Analytics Server,” on page 83 


Prerequisite 


When allocating cluster resources to support a high availability (HA) installation, consider the 
following requirements: 


Ensure that each cluster node that hosts the Analytics Server services meet the requirements 
specified in Section 5.1.1, “System Requirements,” on page 71. 


Ensure that sufficient shared storage is available for the Analytics Server data and application. 
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Ensure that you use a virtual IP address for the services that can be migrated from node to node 
on failover. 


Ensure that your shared storage device meets the performance and size characteristics 
requirements. It is recommended to use a standard SUSE Linux VM configured with iSCSI 
Targets as shared storage. 


Ensure that you have only two cluster nodes that meet the resource requirements for running 
Analytics Server in the cluster environment. 


Ensure you have a virtual IP that can be migrated from one node to another node in a cluster to 
serve as the external IP address for Analytics Server. 


Ensure you create a method for the cluster nodes to communicate with the shared storage, such 
as FibreChannel for a SAN. NetIQ recommends a dedicated IP address to connect to the iSCSI 
Target. 


Ensure you have at least one IP address per cluster node for internal cluster communications. 
NetIQ recommends a simple unicast IP address, but multicast is preferred for production 
environments. 


5.3.2 Installing Analytics Server in High Availability Environment 


To install Analytics Server in High Availability mode, perform the following: 


¢ Section 5.3.2.1, “Initial Setup,” on page 75 

¢ Section 5.3.2.2, “Shared Storage Setup,” on page 76 

¢ Section 5.3.2.3, “Configuring Analytics Server for High Availability on the Nodes,” on page 78 
¢ Section 5.3.2.4, “Cluster Installation and Configuration,” on page 79 

¢ Section 5.3.2.5, “Resource Configuration,” on page 81 


5.3.2.1 Initial Setup 


Configure the computer hardware, network hardware, storage hardware, operating systems, user 
accounts, and other basic system resources per the documented requirements for Analytics Server 
and local customer requirements. Test the systems to ensure proper function and stability. 


Use the following checklist to guide you through initial setup and configuration: 


+ The CPU, RAM, and disk space characteristics for each cluster node must meet the system 
requirements defined in Section 5.1.1, “System Requirements,” on page 71 based on the 
expected event rate. 


¢ If you want to configure the operating system firewalls to restrict access to Analytics Server and 
the cluster, refer to Table 1-6 on page 34, for details of which ports must be available depending 
on your local configuration and the sources that will be sending event data. 


+ Ensure that all cluster nodes are time-synchronized. You can use NTP or a similar technology for 
this purpose. 


+ The cluster requires reliable host name resolution. Enter all internal cluster host names into the / 
etc/hosts file to ensure cluster continuity in case of DNS failure. 


+ Ensure that you do not assign a host name to a loopback IP address. 


+ When configuring host name and domain name while installing the operating system, deselect 
Assign Hostname to Loopback IP. 


+ The nodes will have one NIC for external access and one for iSCSI communications. 
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+ Configure the external NICs with IP addresses that allow for remote access through SSH or 
similar. For this example, we will use 172.16.0.1 (node01) and 172.16.0.2 (node02). 


+ Each node should have sufficient disk for the operating system, and Analytics Server. For 
system requirements, see Section 5.1.1, “System Requirements,” on page 71. 


+ One SUSE Linux 11 SP3 VM configured with iSCSI Targets for shared storage 


+ (Conditional) You can install X Windows if you require GUI configuration. Set the boot 
scripts to start without X (runlevel 3), so you can start them only when needed. 


+ The system will have two NICs: one for external access and one for iSCSI communications. 


+ Configure the external NIC with an IP address that allows for remote access using SSH or 
similar. For example, 172.16.0.3 (storage03). 


+ The system should have sufficient space for the operating system, temp space, a large 
volume for shared storage to hold Sentinel data, and a small amount of space for an SBD 
partition. See the SUSE Linux system requirements, and Sentinel event data storage 
requirements. 


+ Perform the steps mentioned in the following sections. 


NOTE: In a production cluster, you can use internal, non-routable IPs on separate NICs (possibly a 
couple, for redundancy) for internal cluster communications. 


Shared Storage Setup 


Set up your shared storage and make sure that you can mount it on each cluster node. If you are 
using FibreChannel and a SAN, you might need to provide physical connections as well as additional 
configuration. Analytics Server uses this shared storage to store the databases and event data. 
Ensure that the shared storage is appropriately sized accordingly based on the expected event rate 
and data retention policies. 


A typical implementation might use a fast SAN attached using FibreChannel to all the cluster nodes, 
with a large RAID array to store the local event data. As long as the cluster node can mount the 
shared storage as a normal block device, it can be used by the solution. 


NOTE: NetIQ recommends that you configure your shared storage and test mounting it on each 
cluster node. However, the cluster configuration will handle the actual mount of the storage. 


NetIQ recommends using the following procedure to create iSCSI Targets hosted by a SLES 
VM: 
1 Connect to storage03, the VM you created during Initial Setup, and start a console session. 


2 Use the dd command to create a blank file of any desired size for Analytics Server shared 
storage. For creating a 20 GB file filled with zeros copied from the /dev/zero pseudo-device 
file, run the following command: 


dd if=/dev/zero of=/localdata count=20480000 bs=1024 
Configure iSCSI targets 


Configure the files localdata as iSCSI Targets: 


1 Run YaST from the command line (or use the Graphical User Interface, if preferred): /sbin/ 
yast 


2 Select Network Devices > Network Settings. 
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3 Ensure that the Overview tab is selected. 
4 Select the secondary NIC from the displayed list, then tab forward to Edit and press Enter. 


5 On the Address tab, assign a static IP address of 10.0.0.3. This will be the internal iSCSI 
communications IP. 


6 Click Next, then click OK. 
7 On the main screen, select Network Services > iSCSI Target. 


8 If prompted, install the required software (iscsitarget RPM) from the SUSE Linux 11 SP3 
media. 


9 Click Service, select the When Booting option to ensure that the service starts when the 
operating system boots. 


10 Click Global, and then select No Authentication because the current OCF Resource Agent for 
iSCSI does not support authentication. 


11 Click Targets and then click Add to add a new target. 


The iSCSI Target will auto-generate an ID and then present an empty list of LUNs (drives) that 
are available. 


12 Click Add to add a new LUN. 


13 Leave the LUN number as 0, then browse in the Path dialog (under Type=fileio) and select the / 
localdata file that you created. If you have a dedicated disk for storage, specify a block device, 
such as /dev/sdc. 


14 Leave the other options at their defaults. Click OK and then click Next. 


15 Click Next again to select the default authentication options, then Finish to exit the configuration. 
Accept if asked to restart iSCSI. 


16 Exit YaST. 


NOTE: This procedure exposes two iSCSI Targets on the server at IP address 10.0.0.3. At each 
cluster node, ensure that it can mount the local data shared storage device. 


Configuring iSCSI initiators 
Use the following procedure to format the devices: 


Connect to one of the cluster nodes (node01) and start YaST. 

Select Network Devices > Network Settings. 

Ensure that the Overview tab is selected. 

Select the secondary NIC from the displayed list, then tab forward to Edit and press Enter. 


Click Address, assign a static IP address of 10.0.0.1. This will be the internal iSCSI 
communications IP. 


Select Next, then click OK. 
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6 
7 Click Network Services > iSCSI Initiator. 
8 If prompted, install the required software (open-iscsi RPM) from the SUSE Linux 11 SP3 media. 
9 Click Service, select When Booting to ensure the iSCSI service is started on boot. 

10 Click Discovered Targets, and select Discovery. 

11 Specify the iSCSI Target IP address (10.0.0.3), select No Authentication, and then click Next. 

12 Select the discovered iSCSI Target with the IP address 10.0.0.3 and then select Log In. 

13 Switch to automatic in the Startup drop-down and select No Authentication, then click Next. 
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14 
15 


16 
17 


18 


19 


20 
21 


Switch to the Connected Targets tab to ensure that we are connected to the target. 


Exit the configuration. This should have mounted the iSCSI Targets as block devices on the 
cluster node. 


In the YaST main menu, select System > Partitioner. 


In the System View, you should see new hard disk (such as /dev/sdb) in the list - they will have 
a type of IET-VIRTUAL-DISK. Tab over to this hard disk, select it, then press Enter. 


Select Add to add a new partition to the empty disk. Format the disk as a primary ext3 partition, 
but do not mount it. Ensure that the option Do not mount partition is selected. 


Select Next, then Finish after reviewing the changes that will be made. Assuming you create a 
single large partition on this shared iSCSI LUN, you should end up with a /dev/sdb1 or similar 
formatted disk (referred to as /dev/<SHARED1> below). 


Exit YaST. 


Repeat steps 1-15 to ensure that each cluster node can mount the local shared storage. 
Replace the node IP in step 5 with a different IP for each cluster node. 


Configuring Analytics Server for High Availability on the Nodes 


Install Analytics Server to each cluster node that can host it. After you install Analytics Server the first 
time, you must perform a complete installation including the application binaries, configuration, and 
all the data stores. For subsequent installations on the other cluster nodes, you will only install the 
application. The Analytics Server data will be available once you have mounted the shared storage. 


First node 


To configure Analytics Server for HA, perform the following steps: 


5.3.2.3 
1 
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Connect to one of the cluster nodes (node01) and open a console window. 
Navigate to the following directory: 


cd /opt/novell/sentinel/setup 


Record the configuration: 
3a Execute the following command: 
./configure.sh --record-unattended=/tmp/install.props --no-start 
This step records the configuration in the file install. props,which is required to configure 
the cluster resources using the install-resources.sh script. 
3b Specify the Standard configuration option for Analytics Server Configuration method. 
3c Specify 2 to enter a new password. 


Even if you require to use the existing password, choose 2 so that the password is stored 
and synchronized with the other node. 


If you specify 1, the install. props file does not store the password. 
Shut down Analytics Server services by using the following commands: 


/etc/init.d/novell-offline stop 
/etc/init.d/novell-realtime stop 
/etc/init.d/novell-jcc stop 
rcsentinel stop 

insserv -r sentinel 


Installing Analytics Server 


5.3.2.4 


5 Move the Analytics Server data folder to the shared storage using the following commands. This 
movement allows the nodes to utilize the Analytics Server data folder through shared storage. 


mkdir -p /tmp/new 

mount /dev/<SHARED1> /tmp/new 

mv /var/opt/novell/sentinel /tmp/new 
umount /tmp/new/ 


6 Verify the movement of the Analytics Server data folder to the shared storage using the following 
commands: 


mount /dev/<SHARED1> /var/opt/novell/ 


umount /var/opt/novell/ 


Subsequent node 


1 Connect to second cluster node (node02) and open a console window. 
2 Execute the following command: 


insserv -r sentinel 

3 Stop Analytics Server services. 
rcsentinel stop 

4 Remove Analytics Server directory. 
rm -rf /var/opt/novell/sentinel 


At the end of this process, Analytics Server should be installed on all nodes, but it will likely not work 
correctly on any but the first node until various keys are synchronized, which will happen when we 
configure the cluster resources. 


Cluster Installation and Configuration 


Analytics Server includes the cluster software and does not require manual installation. 


As part of this configuration, you can also set up fencing and Shoot The Other Node In The Head 
(STONITH) resources to ensure cluster consistency. 


For this solution you must use private IP addresses for internal cluster communications, and use 
unicast to minimize the need to request a multicast address from a network administrator. You must 
also use an iSCSI Target configured on the same SUSE Linux VM that hosts the shared storage to 
serve as a Split Brain Detection (SBD) device for fencing purposes. 


NetIQ Recommends the following procedure for cluster configuration: 


SBD Setup 


1 Connect to storage03 and start a console session. Use the dd command to create a blank file of 
any desired size: 


dd if=/dev/zero of=/sbd count=1024 bs=1024 


2 Create a 1MB file filled with zeros copied from the /dev/zero pseudo-device. 
3 Run YaST from the command line or the Graphical User Interface: /sbin/yast 
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Select Network Services > iSCSI Target. 

Click Targets and select the existing target. 

Select Edit. The UI will present a list of LUNs (drives) that are available. 

Select Add to add a new LUN. 

Leave the LUN number as 1. Browse in the Path dialog and select the /sbd file that you created. 


Leave the other options at their defaults, then select OK then Next, then click Next again to 
select the default authentication options. 


Click Finish to exit the configuration. Restart the services if needed. Exit YaST. 


NOTE: The following steps require that each cluster node be able to resolve the hostname of all other 
cluster nodes (the file sync service csync2 will fail if this is not the case). If DNS is not set up or 
available, add entries for each host to the /etc/hosts file that list each IP and its hostname (as 
reported by the hostname command). Also, ensure that you do not assign a hostname to a loopback 
IP address. 


Perform the following steps to expose an iSCSI Target for the SBD device on the server at IP address 
10.0.0.3 (storage03). 


Node Configuration 


Connect to a cluster node (node01) and open a console: 
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Run YaST. 

Open Network Services > iSCSI Initiator. 

Select Connected Targets, then the iSCSI Target you configured above. 
Select the Log Out option and log out of the Target. 


Switch to the Discovered Targets tab, select the Target, and log back in to refresh the list of 
devices (leave the automatic startup option and No Authentication). 


Select OK to exit the iSCSI Initiator tool. 


7 Open System > Partitioner and identify the SBD device as the 1MB IET-VIRTUAL-DISK. It will 


be listed as /dev/sdc or similar - note which one. 
Exit YaST. 


Execute the command 1s -1 /dev/disk/by-id/ and note the device ID that is linked to the 
device name you located above. 


Execute the command sleha-init. 
When prompted for the network address to bind to, specify the external NIC IP (172.16.0.1). 
Accept the default multicast address and port. We will override this later. 


Enter 'y' to enable SBD, then specify /dev/disk/by-id/<device id>, where <device id>is 
the ID you located above (you can use Tab to auto-complete the path). 


Complete the wizard and make sure no errors are reported. 

Start YaST. 

Select High Availability > Cluster (or just Cluster on some systems). 
In the box at left, ensure Communication Channels is selected. 


Tab over to the top line of the configuration, and change the udp selection to udpu (this disables 
multicast and selects unicast). 


Select to Add a Member Address and specify this node (172.16.0.1), then repeat and add the 
other cluster node(s): 172.16.0.2. 
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20 Select Finish to complete the configuration. 
21 Exit YaST. 
22 Run the command /etc/rc.d/openais restart to restart the cluster services with the new 
sync protocol. 
Connect to other cluster node (node02) and open a console: 


1 Run YaST. 

2 Open Network Services > iSCSI Initiator. 

3 Select Connected Targets, then the iSCSI Target you configured above. 
4 Select the Log Out option and log out of the Target. 


5 Switch to the Discovered Targets tab, select the Target, and log back in to refresh the list of 
devices (leave the automatic startup option and No Authentication). 


6 Select OK to exit the iSCSI Initiator tool. 

7 Run the following command: sleha-join 
Enter the IP address of the first cluster node. 

8 Run crm_mon on each cluster node to verify that the cluster is running properly. 

(Conditional) If the cluster does not start correctly, perform the following steps: 

1 Manually copy /etc/corosync/corosync.conf from node01 to node02, or run csync2 -x -vV 
on node01, or manually set the cluster up on node02 through YaST. 

2 Run /etc/rc.d/openais start on node02 


(Conditional) If the xinetd service does not properly add the new csync2 service, the script will 
not function properly. The xinetd service is required so that the other node can sync the cluster 
configuration files down to this node. If you see errors like csync2 run failed, you may have 
this problem. 


To resolve this issue, execute the kill -HUP `cat /var/run/xinetd.init.pid command and 
then re-run the sleha-join script. 


3 Run crm_mon on each cluster node to verify that the cluster is running properly. You can also use 
'hawk', the web console, to verify the cluster. The default login name is hacluster and the 
password is linux. 


Perform the following tasks to modify additional parameters: 
1 To ensure that in a single node failure in your two-node cluster does not unexpectedly stop the 
entire cluster, set the global cluster option no-quorum-policy to ignore: 
crm configure property no-quorum-policy=ignore 


2 To ensure that the resource manager allows resources to run in place and move, set the global 
cluster option default -resource-stickiness to 1: 


crm configure property default-resource-stickiness=1 


Resource Configuration 


Resource Agents are provided by default with SLE HAE. If you do not want to use SLE HAE, you 
need to monitor these additional resources using an alternate technology: 


+ A filesystem resource corresponding to the shared storage that the software uses. 
+ An IP address resource corresponding to the virtual IP by which the services will be accessed. 
+ The PostgreSQL database software that stores configuration and event metadata. 
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NetiQ recommends the following for resource configuration: 


NetIQ provides a crm script to aid in cluster configuration. The script pulls relevant configuration 
variables from the unattended setup file generated as part of the Analytics Server installation. If you 
did not generate the setup file, or you wish to change the configuration of the resources, you can use 
the following procedure to edit the script accordingly. 


The proceeding steps must be performed on the nodes on which Analytics Server is installed. 


1 Run the following commands on both nodes: 
+ mkdir -p /var/log/agg-analytics-var 
+ mkdir -p /var/log/agg-analytics-var/nam/logs/dashboard/tomcat 
+ chown -R novell.novell /var/log/agg-analytics-var/ 
2 On the primary node, run the following commands in the same sequence, where <SHARED1> is 
the shared volume you created previously: 
mount /dev/<SHARED1> /var/opt/novell 
ln -s /var/log/agg-analytics-var/nam /var/opt/novell/nam 
cd /usr/lib/ocf/resource.d/novell 


./install-resources.sh 


The install-resources.sh script will prompt you for a couple values, namely the virtual IP that 
you would like people to use to access Analytics Server and the device name of the shared 
storage, and then will auto-create the required cluster resources. Note that the script requires the 
shared volume to already be mounted, and also requires the unattended installation file which 
was created during Analytics Server install to be present (/tmp/install.props). You do not 
need to run this script on any but the first installed node; all relevant config files will be 
automatically synced to the other nodes. 


After running the install-resources script, if you get the error for the file syncronization, then run 
csync2 -x -v. If you get the message that file is up to date and is with no errors, then you can 
continue the deployment. 


3 Run the following commands on the primary node: 
+ /etc/init.d/novell-offline start 
+ /etc/init.d/novell-realtime start 
+ /etc/init.d/novell-jcc start 

4 Run /etc/rc.d/openais restart on node02. 


5 If your environment varies from this NetIQ recommended solution, you can edit the 
resources.cli file (in the same directory) and modify the primitives definitions from there. For 
example, the recommended solution uses a simple Filesystem resource; you may wish to use a 
more cluster-aware cLVM resource. 


6 After running the shell script, you can issue a crm status command and the output should look 
like this: 


crm status 


Last updated: Thu Jul 26 16:34:34 2012 

Last change: Thu Jul 26 16:28:52 2012 by hacluster via crmd on node01 
Stack: openais 

Current DC: node01 - partition with quoru 

Version: 1.1.6- b988976485d15cb762c9307d'55512d323831a5e 

2 Nodes configured, 2 expected votes 

5 Resources configured. 
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5.3.3.1 


5.3.3.2 


Online: [ node01, node02 ] 


stonith-sbd (stonith:external/sbd): Started node01 

Resource Group: sentinelgrp 
sentinelip (ocf: :heartbeat:IPaddr2): Started node01 
sentinelfs (ocf: :heartbeat:Filesystem): Started node01 
sentineldb (ocf::novell:pgsql): Started node01 
sentinelserver (ocf::novell:sentinel): Started node01 


7 Add the following entry to /etc/csync2/csync2.cfg: 


include /etc/opt/novell/sentinel/config/auth. login; 
include /etc/opt/novell/nam/sentinelReportAdminConfig; 


8 Runcsync2 -x -v. 
Run the command again if you get any error. 


NOTE: The preceeding steps are used for installing and configuring the cluster for high availability. 
However, to use this cluster configuration, you must enable clustering from Administration Console. 


For more information, refer Section 5.3.3, “Post-Installation Cluster Configuration for Analytics 
Server,” on page 83. 


Post-Installation Cluster Configuration for Analytics Server 


After performing the cluster installation steps, you can view the active and standby nodes in 


Administration Console. But to use Analytics Server in high availability mode you must perform the 


following in Administration Console in the same sequence: 


¢ Section 5.3.3.1, “Enable Clustering,” on page 83 
¢ Section 5.3.3.2, “Configure the settings for auditing,” on page 83 


Enable Clustering 


1 Click Devices > Analytics Server. 


2 In the cluster row, click Edit. 


3 In the Cluster Configuration section, set the Clustering is Configured: field to Yes and specify 


the same virtual IP address in the Cluster’s Virtual IP: field that you had specified during 
resource configuration. For more information, seeStep 2 on page 82. 


Configure the settings for auditing 


Analytics Server will be functional only when it is set as the audit server in Administration Console. To 


set it as the audit server perform the following: 


1 Perform the steps mentioned in “Enable Clustering” on page 83. 
2 In the Admin Tasks pane, click Auditing. 
3 In the Audit Messages Using: field, Select Syslog: > Send to Analytics Server 


The Server Listening Address gets auto-populated with the virtual IP address that you had 
specified when performing step 1. 


Installing Analytics Server 


83 


84 Installing Analytics Server 


Installing Packages and Dependent 
RPMs on RHEL for Access Manager 


The following table lists RHEL packages and their dependent RPMs required for each component. 


NOTE: 


You must install the RHEL Enterprise Server-with-GUI. Run the sudo yum groupinstall "Server 
with GUI" command to obtain the required RPMs. 


To avoid RPM dependency issues, NetIQ Corporation recommends installing the package along with 
its respective dependent RPMs. You can also install all packages together in the same sequence as 
these appear in the table. 


The version of RPMs varies based on the base operating system version of RHEL. The following 
table lists RPMs for RHEL 7.2. 


You must install these RPMs in the same sequence as they appear in the table: 


Package Dependent RPM 
iManager 
glibc-2.17-105.el7.i686.rpm + nss-softokn-freebl-3.16.2.3-13.el7_1.i686 


This must be installed along with glibc-2.17- 
105.el7.i686.rpm. To install these rpm files 
together, run the following: 


rpm -ivh glibc-2.17-105.e17.1686.rpm 
nss-softokn-freebl-3.16.2.3- 
13.e17_1.1686.rpm 


libstdc++-4.8.2-16.el7.i686.rpm + glibc-2.17-55.el7.i686.rpom 

These RPMs are required for the Administration + libgcc-4.8.2-16.el7.i686.rpm 

Console also. 

libstdc++-4.8.5-4.el7.x86_64.rpm + glibc-2.17-55.el7.i686.x86_64.rpm 
(Part of the RHEL base installation) + libgcc-4.8.2-16.el7.i686.rpm.x86_64.rpm 
libstdc++-4.8.3-9.el7.i686 + glibc-2.17-78.el7.i686 


+ libgcc-4.8.3-9.el7.i686 


libstdc++-4.8.3-9.el7.x86_64 + libgcc-4.8.3-9.el7.x86_64 
libXau-1.0.8-2.1.el7.x86_64.rpm + glibc-2.17-55.el7.i686.rom 
libxcb-1.9-5.el7.x86_64.rpm + glibc-2.17-55.el7.i686.rpom 


+ libXau-1.0.8-2.1.el7.x86_64.rpm 
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Package 


libX11-1.6.0-2.1.el7.x86_64.rpm 


Dependent RPM 


glibc-2.17-55.el7.i686.rpm 
libXau-1.0.8-2.1.el7.x86_64.rpm 


libXext-1.3.2-2.1.el7.x86_64.rpm 


libX11-1.6.0-2.1.el7.x86_64.rpm 
glibc-2.17-55.el7.i686.rom 


libXi-1.7.2-2.1.el7.x86_64.rpm 


libX11-1.6.0-2.1.el7.x86_64.rpm 
libXext-1.3.2-2.1.el7.x86_64.rpm 
glibc-2.17-55.el7.i686.rpom 


libXtst-1.2.2-2.1.el7.x86_64.rpm 


libX11-1.6.0-2.1.el7.x86_64.rpm 
libXext-1.3.2-2.1.el7.x86_64.rpm 
libXi-1.7.2-2.1.el7.x86_64.rpm 
glibc-2.17-55.el7.i686.rpom 


libxcb-1.11-4.el7.i686.rpm 


libXau-1.0.8-2.1.e17.i686.rpm 


libX11-1.6.3-2.el7.i686.rpm 


libxcb-1.11-4.el7.i686.rpm 


libXtst-1.2.2-2.1.el7.i686.rpm 


libX11-1.6.3-2.el7.i686.rom 
libXi-1.7.4-2.el7.i686.rom 
libXext-1.3.3-3.el7.i686.rom 


libXrender-0.9.8-2.1.el7.i686.rom 
Administration Console 


gettext-0.18.2.1-4.el7.x86_64 


No dependency 


No dependency 


glibc-2.17-78.el7.i686.rpm 


nss-softokn-freebl-3.16.2.3-9.el7.i686 


libstdc++-4.8.2-16.el7.i686.rpom 


glibc-2.17-55.el7.i686.rom 
libgcc-4.8.2-16.el7.i686.rpm 


ncurses-libs-5.9-13.20130511.el7.i686.rpom 


glibc-2.17-55.el7.i686.rom 


libgcc-4.8.2-16.el7.i686.rpm 


No dependency 


rsyslog-7.4.7-7.el7_0.x86_64 


No dependency 


rsyslog-gnutls-7.4.7-7.el7_0.x86_64 


No dependency 


binutils-2.23.52.0.1-30.el7.x86_64 


No dependency 


gperftools-libs-2.4-7.el7.x86_64 


No dependency 


Identity Server 


glibc-2.17-78.el7.i686.rpom 


nss-softokn-freebl-3.16.2.3-9.el7.i686 


libstdc++-4.8.2-16.el7.i1686 


glibc-2.17-55.el7.i686.rom 
libgcc-4.8.2-16.el7.i686.rom 


ncurses-libs-5.9-13.20130511.el7.i686.rpom 


glibc-2.17-55.el7.i686.rpom 


libgcc-4.8.2-16.el7.i686.rpm 


No dependency 
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Package 


rsyslog-7.4.7-7.el7_0.x86_64 


Dependent RPM 


+ 


No dependency 


rsyslog-gnutls-7.4.7-7.el7_0.x86_64 


+ 


No dependency 


binutils-2.23.52.0.1-30.el7.x86_64 


+ 


No dependency 


Access Gateway 


glibc-2.17-78.el7.i686.rpom 


nss-softokn-freebl-3.16.2.3-9.el7.i686 


db4-4.7.25-17.el6.x86_64.rpm 
(Part of the RHEL base installation) 


glibo-2.17-55.el7.i686.x86_64.rpm 


apr-1.4.8-3.el7.x86_64.rpm 


glibo-2.17-55.el7.i686.x86_64.rpm 


apr-util-1.5.2-6.el7.x86_64.rpm 


apr-1.4.8-3.el7.x86_64.rom 
glibc-2.17-55.el7.i686.x86_64.rpm 


libtool-ltdl-2.4.2-20.el7.x86_64.rpm 


unixODBC-2.3.1-10.el7.x86_64.rpm 


glibo-2.17-55.el7.i686.x86_64.rpm 


libtool-Itdl-2.4.2-20.el7.x86_64.rpm 
glibo-2.17-55.el7.i686.x86_64.rpm 


libesmtp-1.0.6-7.el7.x86_64.rpm 


glibc-2.17-55.el7.i686.x86_64.rpm 


rsyslog-7.4.7-7.el7_0.x86_64 


No dependency 


rsyslog-gnutls-7.4.7-7.el7_0.x86_64 


No dependency 


binutils-2.23.52.0.1-30.el7.x86_64 


No dependency 


patch-2.7.1-8.el7.x86_64.rpm 


No dependency 


Use the following command to verify whether a package is installed on RHEL: 
rpm -qa | grep <package name> 

Use the following command to install a RPM: 

rpm -ivh <rpm name> 

Use the following command to install all RPMs together: 


rpm -ivh <rpm name> <rpm name> <rpm name >... 


NOTE: The version of RPMs varies based on the base operating system version of RHEL. 


Perform the following steps to install packages and their dependent RPMs while installing RHEL: 
1 Mount the RHEL CD-ROM by running the following command and go to the Packages folder.: 


mount /dev/cdrom /mnt 


NOTE: If the RHEL CD-ROM is auto mounted, the mount path will be /media/RHEL_x.x x86_64 
Disc 1. (The x in RHEL_x.x represents the version number) Unmount the default mount path by 
using the unmount /media/RHEL_x.x\ x86_64\ Disc\ 1/command and then mount the RHEL 


CD-ROM by using mount /dev/cdrom /mnt. 
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2 If you have a locally mounted ISO image, you can install RPMs for Access Manager by providing 
the mount path to the installer. The install.sh scripts prompts for the mounted disc if it 
identifies that the required RPMs are not installed. Provide the mount path to the installer with an 
ending /. For example, /mnt/. 


NOTE: Installer will install only RPMs required for Access Manager components. You need to 
install iManager RPMs separately. 


Install RPMs for SNMP after installing RPMs for the Administration Console. See “RHEL 
Packages and Their Dependent RPMs for SNMP” on page 88. 


You must install RPMs in the same sequence as these appear in the table. 


RHEL Packages and Their Dependent RPMs for SNMP 


The RHEL base installation does not install the net-snmp package by default. Install the following 
packages manually to make the net-snmp service (Master Agent) functional: 

+ net-snmp-libs-5.7.2-18.el7.x86_64.rpm 

+ net-snmp-5.5-44.el6.x86_64 


Use the following procedure to install these packages to avoid any dependency issue: 


1 Mount the RHEL CD-ROM by running the following command: 
mount /dev/cdrom /mnt 

2 Run the following commands: 
yum install --nogpgcheck net-snmp-libs-5.7.2-18.e17.x86_64.rpm 
yum install --nogpgcheck net-snmp-5.5-44.e16.x86_64 


3 After installation, run /etc/init.d/novell-snmpd start. This will succeed for a successful 
installation. 
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7.1 


7.1.1 


7.1.2 


Uninstalling Components 


This section provides the required uninstallation steps: 


¢ Section 7.1, “Uninstalling the Identity Server,” on page 89 

¢ Section 7.2, “Reinstalling an Identity Server to a New Hard Drive,” on page 90 
¢ Section 7.3, “Uninstalling Access Gateway,” on page 91 

¢ Section 7.4, “Uninstalling the Administration Console,” on page 92 


Uninstalling the Identity Server 


Uninstalling the NetlQ Identity Server is a two-step process: 
1. Removing the Identity Server from the Administration Console. See Section 7.1.1, “Deleting 
Identity Server References,” on page 89. 


2. Removing the Identity Server software from the Linux or Windows machine. See Section 7.1.2, 
“Uninstalling the Linux Identity Server,” on page 89 or Section 7.1.3, “Uninstalling the Windows 
Identity Server,” on page 90. 


Deleting Identity Server References 


As part of the full Identity Server uninstall process, you must delete the Identity Server from the 
Administration Console. The Identity Server must first be removed from the cluster configuration, then 
it can be deleted from the Administration Console. You must do this before removing the software 
from the machine. 

1 In the Administration Console, click Devices > Identity Servers. 
Select the Identity Server that you want uninstalled, then click Stop. 
Wait for its health to turn red, then select the server and click Actions > Remove from Cluster. 
Update the cluster configuration. 
Select the Identity Server that you are going to uninstall, then click Actions > Delete. 
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Continue with Section 7.1.2, “Uninstalling the Linux Identity Server,” on page 89 or Chapter 7, 
“Uninstalling Components,” on page 89. 


Uninstalling the Linux Identity Server 


If you have installed the Identity Server with the Administration Console, you can select to uninstall 
only the Identity Server or to uninstall both. 

1 On your Linux Identity Server, insert the Access Manager installation CD. 

2 Navigate to the novell-access-manager directory. 

3 Enter ./uninstall. sh to initiate the uninstallation script. 

4 Select 2 to uninstall the Identity Server. 
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5 


Enter the name and password of the admin user. (When Administration Console and Identity 
Server are installed on the same server) 


Uninstall removes the Identity Server. A log file is created at /tmp/ 
novell_access_manager_uninstall.1log. 


7.41.3 Uninstalling the Windows Identity Server 


If you have installed the Identity Server with the Administration Console, you can select to uninstall 
only the Identity Server or to uninstall both. 


1 
2 


Exit any applications and disable any virus scanning programs. 


Access the Control Panel, click Add or Remove Programs, then select to remove the 
AccessManagerServer program. 


3 Read the introduction, then click Next. 


Specify the credentials for the admin user, then click Next. 


5 Select one of the following, then click Next. 


Complete Uninstall: Select this option if you have installed both the Identity Server and the 
Administration Console on the same machine and you want to uninstall both. 


Uninstall Specific Features: Select this option to uninstall only the Identity Server. 


(Conditional) If you selected to uninstall specific features, select one of the following, then click 
Uninstall. 


+ Administration Console: Select this option to uninstall the Administration Console. You 
cannot uninstall the Administration Console without also uninstalling the Identity Server. 


¢ Identity Server: Select this option to uninstall only the Identity Server. 


If the unistall fails because the primary Administration Console is not available to validate the 
credentials, see “Uninstalling the Windows Identity Server” on page 90. 


(Conditional) If Administration Console was installed with Identity Server and you selected only 
to uninstall Identity Server, reboot the machine. 


7.2 Reinstalling an Identity Server to a New Hard Drive 


If your Identity Server hard drive fails, you must reinstall the Identity Server (see Chapter 3, “Installing 
the Identity Servers,” on page 49) and leave the Identity Server configuration intact in the 
Administration Console. In order to preserve the existing keystores, perform the following steps 
before installing the Identity Server on the new hard drive. 


1 
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Stop the server. 


In the Administration Console, click Access Manager > Identity Servers. Select the server and 
click Stop. Allow a few seconds for the server to stop. 


Select the server, then click Actions > Remove from configuration. 

Select the server, then click Actions > Delete. 

Reinstall the Identity Server. (See Chapter 3, “Installing the Identity Servers,” on page 49.) 
On the Identity Servers page, select the server, then click Actions > Assign to Cluster. 
Select the Identity Server cluster configuration, then click Assign. 

Click OK. 
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7.3 Uninstalling Access Gateway 


1 In the Administration Console, click Access Gateways. 

2 If the Access Gateway belongs to a cluster, you need to remove it from the cluster. 
2a Select the Access Gateway, then click Actions > Remove from Cluster: 
2b Confirm the action, then click OK. 


3 On the Access Gateways Servers page, select the name of the server, then click Actions > 
Delete > OK. 


This removes the configuration object for the Access Gateway from the Administration Console. 


4 On the Identity Servers page, update the Identity Server status for the Identity Server cluster 
configuration that was using this Access Gateway. 


See Updating an Identity Server Configuration in the NetIQ Access Manager 4.3 Administration 
Guide. 


5 Complete one of the following: 


+ If you are uninstalling the Access Gateway Appliance machine, re-image the machine by 
booting to a CD containing the desired operating system software. 


+ If you are uninstalling the Windows Access Gateway Service, continue with Section 7.3.1, 
“Uninstalling Windows Access Gateway Service,” on page 91. 


+ If you are uninstalling the Linux Access Gateway Service, continue with Section 7.3.2, 
“Uninstalling Linux Access Gateway Service,” on page 91. 


7.3.1 Uninstalling Windows Access Gateway Service 


1 Exit any applications and disable any virus scanning programs. 


2 Access the Control Panel, click Add or Remove Programs and select to remove the 
AccessGateway program. 


3 Click Next. 
4 Specify the credentials for the admin user, then click Uninstall. 


If the uninstall fails because the program cannot authenticate to the Administration Console, see 
“Troubleshooting the Uninstall of Access Gateway Service” on page 135. 


7.3.2 Uninstalling Linux Access Gateway Service 


On your Linux Access Gateway Service, insert the Access Manager installation CD. 
Navigate to the novell-access-gateway directory. 

Enter ./uninstall. sh to initiate the uninstallation script. 

Enter the name of the admin user. 
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Enter the password of the admin user. 


Uninstall removes the Access Gateway Service. A log file is created at /tmp/ 
novell_access_manager_uninstall.1log. 


If the uninstall fails, see “Troubleshooting the Uninstall of Access Gateway Service” on page 135. 
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7.4 


7.4.1 


Uninstalling the Administration Console 


Only the primary version of the Administration Console contains the certificate authority. If you 
uninstall this version, you can no longer use Access Manager for certificate management. You need 
to promote a secondary console to be the primary console. See Installing Secondary Versions of 
Administration Console in the NetIQ Access Manager 4.3 Administration Guide. 


IMPORTANT: If you are uninstalling all Access Manager devices, the primary Administration Console 
should be the last device you uninstall. The uninstall programs for the other devices contact the 
primary Administration Console and validate the admin’s credentials before allowing the device to be 
removed. 


Select the process that corresponds to your platform: 


¢ Section 7.4.1, “Uninstalling the Linux Administration Console,” on page 92 


¢ Section 7.4.2, “Uninstalling the Windows Administration Console,” on page 93 


Uninstalling the Linux Administration Console 


1 Insert CD 1 into the drive. 
2 Log in as the root user or equivalent. 
3 At the command prompt of the Access Manager directory, enter the following: 


./uninstall.sh 


4 Select one of the following options: 


Option Description 


1 Novell Access Manager Administration 

2 Novell Identity Server 

3 Novell Access Gateway 

6 Forcefully uninstall all products (not recommended) 


Use this option after a failed installation; otherwise use options 1 through 4 to uninstall Access 
Manager components. 


WARNING: Using this option when you have a cluster of Administration Consoles can cause 
synchronization and update problems with the configuration store. If you use it to remove an 
Administration Console, you need to run dsrepair to remove the missing replica from the replica 
ring. 


Q Quit without uninstalling 


5 After running the. /uninstall.sh script, go to Auditing > Troubleshooting > Other Known 
Device Manager Servers, then remove the entry for this secondary Administration Console from 
the servers list. 


A log file is created at /tmp/novell_access_manager_uninstall.1og. 
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7.4.2 Uninstalling the Windows Administration Console 


When you uninstall the Administration Console, any other Access Manager components on the 
machine must also be uninstalled. 
1 Exit any applications and stop any virus scanning programs. 


2 Access the Control Panel, click Add or Remove Programs, then select to remove the 
AccessManagerServer program. 


3 Read the introduction, then click Next. 

4 Specify the credentials for the admin user, then click Next. 
5 Click Complete Uninstall, then click Next. 

6 Restart the machine. 


NOTE: Some services are not completely removed. To remove it completely, you must remove few 
registry settings after restarting the server. For information about removing required registry settings, 
refer “Deleting Services from Registry” on page 93. 


7.4.2.1 Deleting Services from Registry 


When you uninstall Administration Console by using the steps mentioned in Section 7.4.2, 
“Uninstalling the Windows Administration Console,” on page 93, some service are not deleted. To 
delete the required services to uninstall Administration Console completely from the machine, 
perform the following steps: 

1 Stop SLP service 

2 Back up the registry settings 

3 Remove HKLM>SOFTWARE>Wow6432Node>Apache Software Foundation 

4 Remove HKLM>SOFTWARE>Novell 
5 


Remove 
HKLM>SOFTWARE>Wow6432Node>Microsoft>Windows>CurrentVersion\Uninstall>NetIQ 
iManager 


6 Remove HKLM>SOFTWARE>Microsoft>wWindows>CurrentVersion>App Paths>java.exe 
7 Remove HKLM>SOFTWARE>Microsoft>windows>CurrentVersion>Uninstall>NDSonNT 

8 Remove HKLM>SOFTWARE>Wow6432Node>JavaSoft 

9 Remove HKLM>SYSTEM>ControlSet001>Services>EventLog>Application>NDS Server 
0 Remove HKLM>SYSTEM>ControlSet001>Services>NDS Server 

11 Remove HKLM>SYSTEM>ControlSet001>Services>slpd 


12 Remove 
HKLM>SYSTEM>ControlSet001>Services>SNMP>Par ameter s>ExtensionAgents>Novell.eDi 
r-Snmp.1 


13 Remove HKLM>SYSTEM>ControlSet001>Services>Tomcat7 

14 Remove HKLM>SYSTEM>ControlSet002>Services>EventLog>Application>NDS Server 
15 Remove HKLM>SYSTEM>ControlSet002>Services>NDS Server 

16 Remove HKLM>SYSTEM>ControlSet002>Services>slpd 
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17 Remove 
HKLM>SYSTEM>ControlSet002>Services>SNMP>Par ameter s>ExtensionAgents>Novell.eDi 
r-Snmp.1 


18 Remove HKLM>SYSTEM>ControlSet002>Services>Tomcat7 
19 Remove all files from the following location: 

+ C:\Program Files (x86)\Novell 

+ C:\Program Files\Common Files\Novell 

+ C:\Novell\NDS 
20 Restart the machine. 
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Upgrading Access Manager 


This section discusses how to upgrade Access Manager to the newer version. You must take a 
backup of the existing configurations before upgrading Access Manager components. 


For more information, see “Back Up and Restore” in the NetIQ Access Manager 4.3 Administration 
Guide. 


IMPORTANT: After upgrading to Access Manager 4.3, you must clear the browser cache to view the 
upgraded Administration Console. For more information, see TID 7018166. 


If you are upgrading to 4.3 Service Pack 1, then you do not require to clear the browser cache. 


NOTE 


+ By default, Access Manager 4.3 configuration uses stronger TLS protocols, ciphers, and other 
security settings. After upgrading if you want to revert these settings, see Restoring Previous 
Security Level After Upgrading Access Manager in the NetIQ Access Manager 4.3 Security 
Guide . 


+ Platform Agent and Novell Audit are not supported from Access Manager 4.2 onwards. If you 
upgrade from an older version of Access Manager to latest version, Platform Agent is still 
available. It is recommended to use Syslog for auditing. 


This part describes how to upgrade Access Manager components and include the following chapters: 


+ Chapter 8, “Prerequisites,” on page 97 

+ Chapter 9, “Upgrading Access Manager,” on page 101 

e Chapter 10, “Upgrading the Operating System for Access Gateway Appliance,” on page 119 
¢ Chapter 11, “Getting the Latest Security Patches,” on page 121 
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8 Prerequisites 


8.1 


8.1.1 


Before performing an upgrade, ensure that the following prerequisites are met: 


+ Any option that is configured through the nidpconfig. properties file will be overwritten after 
upgrade. Hence, ensure to back up the nidpconfig.properties file before upgrading to 4.3. 
After the upgrade, replace the new nidpconfig.properties file with the backed up file. 


+ Access Manager 4.2 onwards, some of the options are supported only through the 
Administration Console. After the upgrade, you must configure those options through the 
Administration Console. For the list of options that must be configured through Administration 
Console, see Configuring Identity Server Global Options, Configuring ESP Global Options, 
Defining Options for SAML 2.0 in the NetIQ Access Manager 4.3 Administration Guide. 


+ The upgrade process overwrites all customized JSP files. If you have customized JSP files for 
the Identity Server or the Access Gateway, you must perform manual steps to maintain the 
customized JSP files. For more information, see Section 8.1, “Maintaining Customized JSP Files 
for Identity Server,” on page 97 or Section 8.2, “Maintaining Customized JSP Files for Access 
Gateway,” on page 99. 


+ If you have customized any changes to tomcat . conf or server . xml, you must back up the files. 
After the upgrade, restore the files. 


+ If you have installed the unlimited strength java crypto extensions before upgrade, you must re- 
install it after the upgrade because a new Java version will be used. 


+ If you are using Kerberos, ensure that you back up the /opt/novell/nids/1lib/webapp/WEB- 
INF/classes/kerb.properties file. 


Maintaining Customized JSP Files for Identity 
Server 


Access Manager contains a default user portal and a set of default login pages from Access Manager 
4.2 onwards. The new login pages have a different look and feel compared to the default login pages 
of Access Manager 4.1 or prior. If you have customized the legacy user portal, you can maintain the 
customized JSP pages in the following two ways: 

¢ Using Customized JSP Pages from Access Manager 4.1 or Prior 


¢ Using Customized JSP Pages from Access Manager 4.1 or Prior and Enabling the New Access 
Manager Portal 


Using Customized JSP Pages from Access Manager 4.1 or 


Prior 


1 Before upgrade, create a copy of all JSP files inside the /opt/novell/nidp/1lib/webapp/jsp 
directory and place the copy somewhere else. 


WARNING: The upgrade overwrites all existing JSP files. 


2 Upgrade Identity Server. 
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3 Create an empty folder legacy in Identity Server: /opt/novell/nids/1ib/webapp/WEB- INF/ 


legacy. 


NOTE: If you do not create the legacy folder, Access Manager uses the logic of the default new 
login pages. 


4 Copy your all backed up JSP files into the /opt/novell/nids/lib/webapp/jsp directory. 


5 Refresh the browser to see the changes. 


Using Customized JSP Pages from Access Manager 4.1 or 
Prior and Enabling the New Access Manager Portal 


1 


Before upgrade, create a copy of all JSP files inside the /opt/novell/nidp/1lib/webapp/jsp 
directory and place the copy somewhere else. 


WARNING: The upgrade overwrites all existing JSP files. 


Upgrade Identity Server. 


3 Create an empty folder legacy in Identity Server: /opt/novell/nids/1ib/webapp/WEB - INF/ 


legacy. 


NOTE: If you do not create the legacy folder, Access Manager uses the logic of the default new 
login pages. 


4 Copy your all backed up JSP files into the /opt/novell/nids/lib/webapp/jsp directory. 


5 Find the customized nidp.jsp and content. jsp files and make the following changes in both 


files: 
5a In the top Java section of the JSP file, find the ContentHandler object that looks similar to 
the following: 
ContentHandler handler = new ContentHandler (request, response); 


5b In the code, add the following Java line under ContentHand1ler: 


boolean bGotoAlternateLandingPageUrl = 
handler .gotoAlternateLandingPageUr1(); 


5c Find the first instance of <script></script> in the JSP file that is not <script src></ 
script>, then insert the following line in to the JavaScript section between the <script></ 
script> tags: 


<% if (bGotoAlternateLandingPageUrl) { %> 
document.location = "<%=handler.getAlternateLandingPageUr1( )%>"; 
<% } %> 
This redirects control to the default portal page that contains appmarks. 
5d Save the file. 


5e Repeat the steps for the second JSP file. 


6 Refresh the browser to see the changes. 
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Maintaining Customized JSP Files for Access 
Gateway 


If you have customized the JSP files for Access Gateway, you must perform the following steps to 
maintain the customized files: 


1 Before upgrade, create a copy of all JSP files inside the /opt/novell/nesp/1lib/webapp/jsp 
directory and place the copy somewhere else. 


WARNING: The upgrade overwrites all existing JSP files. 


2 Upgrade Access Gateway. 


3 Create an empty folder legacy in Access Gateway: /opt/novell/nesp/1ib/webapp/WEB- INF/ 
legacy. 


NOTE: If you do not create the legacy folder, Access Manager uses the logic of the default new 
login pages. 


4 Copy your all backed up JSP files into the /opt/novell/nesp/lib/webapp/jsp directory. 
5 Refresh the browser to see the changes. 
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Q Upgrading Access Manager 


When you upgrade the Access Manager components, first back up your configuration and then move 
the Administration Console. You can then upgrade the various devices that you have imported into 
the Administration Console. 


You must upgrade the Access Manager components in the following sequence: 


1. Administration Console 

2. Identity Server 

3. Access Gateway 

4. (Optional) Analytics Server 


NOTE 


¢ If you have installed additional nodes of Administration Console on other servers for fault 
tolerance, ensure that primary Administration Console is upgraded first, else the directory 
schema does not get updated. 


+ We recommend that you upgrade all members of a cluster before moving to another type of 
device. 


+ When the nodes in the cluster are running on different release versions, you must not change 
any configuration through Administration Console. 


This table lists Access Manager upgrade and migration path: 


Access Manager Version Upgrade Path to Access Manager 4.3 
4.1.2 or 4.1.2 Hotfix 1 Direct upgrade 

4.2 Direct upgrade 

4.2.1 Upgrade to 4.2.2, then upgrade to 4.3 


For more information about upgrading from 4.2.1 to 
4.2.2, see NetIQ Access Manager 4.2 Installation and 
Upgrade Guide. 


4.2.2 Direct upgrade 


NOTE: Upgrade from Access Manager 4.2.3 to 4.3 is not supported. You can upgrade Access 
Manager 4.2.3 to 4.3.1. 


For information about the latest supported upgrade paths, see the specific Release Notes on the 
Access Manager Documentation website. 

¢ Section 9.1, “Upgrading Access Manager on Linux,” on page 102 

¢ Section 9.2, “Upgrading Analytics Server,” on page 111 

¢ Section 9.3, “Upgrading Analytics Server in a High Availability Setup,” on page 112 

¢ Section 9.4, “Upgrading Access Manager on Windows,” on page 113 
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9.1.1.1 


Upgrading Access Manager on Linux 


¢ Section 9.1.1, “Upgrading the Evaluation Version to the Purchased Version,” on page 102 
¢ Section 9.1.2, “Upgrading Access Manager,” on page 104 


IMPORTANT: If the base operating system is RHEL 6.7, you must first upgrade to Access Manager 


4.3, then upgrade to RHEL 6.8. 


Upgrading the Evaluation Version to the Purchased Version 


If you have downloaded the evaluation version and want to keep your configuration after purchasing 
the product, you need to upgrade each of your components with the purchased version. The upgrade 


to the purchased version automatically changes your installation to a licensed version. 


NOTE: For Analytics Server, an upgrade is not required for the licensed version. 


After you have purchased the product, log in to the NetIQ Customer Center and follow the link that 
allows you to download the product. Then use the following sections for instructions on upgrading the 


components: 


¢ Section 9.1.1.1, “Upgrading Administration Console,” on page 102 

¢ Section 9.1.1.2, “Upgrading Identity Server,” on page 103 

¢ Section 9.1.1.3, “Upgrading Access Gateway Appliance,” on page 104 
¢ Section 9.1.1.4, “Upgrading Access Gateway Service,” on page 104 


Upgrading Administration Console 


If Identity Server is installed on the same machine as Administration Console, Identity Server is 
automatically upgraded with Administration Console. 

1 Open a terminal window. 

2 Log in as the root user. 


3 Download the upgrade file from dl.netig.com and extract the tar.gz file using the following 
command: tar -xzvf <filename>. 


NOTE: For information about the name of the upgrade file, see the specific Release Notes on 


the Access Manager Documentation website. 


4 Change to the directory where you unpacked the file, then enter the following command in a 
terminal window: 


./upgrade.sh 


5 The system displays the confirmation message along with the list of installed components. For 
example, if the Administration Console and Identity Server are installed on the same machine, 


the following message is displayed: 
The following components were installed on this machine 
1. Access Manager Administration Console 


2. Identity Server 
Do you want to upgrade the above components (y/n)? 
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O O NO 


Type Y and press Enter. 

Type Y to continue with the upgrade, then press Enter. 

Enter the Access Manager Administration Console user ID. 

Enter the Access Manager Administration Console password. 

Re-enter the password for verification. 

The system displays the following message when the upgrade is complete: 


Upgrade completed successfully. 


The upgrade logs are located in the /tmp/novell_access_manager/ directory. The logs have 
time stamping. 


If you encounter an error, see “Troubleshooting Linux Administration Console Upgrade” on page 137. 


Upgrading Identity Server 


Use the following procedure to upgrade stand-alone Identity Server. If you have installed both Identity 
Server and Administration Console on the same machine, see “Upgrading Administration Console” 
on page 105. 


NOTE: If you have modified the JSP file to customize the login page, logout page, and error 
messages, you can restore the JSP file after installation. You should sanitize the restored JSP file to 
prevent XSS attacks. For more information, see Preventing Cross-site Scripting Attacks in the NetIQ 
Access Manager 4.3 Administration Guide. 


1 Open a terminal window. 


o ao NO 
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Log in as the root user. 


Download the upgrade file from dl.netiq.com and extract the tar.gz file using the following 
command: tar -xzvf <filename>. 


NOTE: For information about the name of the upgrade file, see the specific Release Notes on 
the Access Manager Documentation website. 


Change to the directory where you unpacked the file, then enter the following command in a 
terminal window: 


./upgrade.sh 

The system displays the following confirmation message: 

The following components were installed on this machine 
1. Identity Server 


Do you want to upgrade the above components (y/n)? 


Type Y and press Enter. 

Type Y to continue with the upgrade, then press Enter. 

Enter the Access Manager Administration Console user ID. 
Enter the Access Manager Administration Console password. 
Re-enter the password for verification. 


Upgrading Access Manager 103 


11 The system displays the following message when the upgrade is complete: 
Upgrade completed successfully. 


The upgrade logs are located in the /tmp/novell_access_manager/ directory. The logs have 
time stamping. 


9.1.1.3 Upgrading Access Gateway Appliance 


1 Open a terminal window. 
2 Log in as the root user. 


3 Download the upgrade file from dl.netig.com and extract the tar.gz file using the following 
command: tar -xzvf <filename>. 


NOTE: For information about the name of the upgrade file, see the specific Release Notes on 
the Access Manager Documentation website. 


4 Change to the directory where you unpacked the file, then enter the following command ina 
terminal window: 


./ma_upgrade.sh 


5 Enter the Access Manager Administration Console user ID. 
6 Enter the Access Manager Administration Console password 
7 Re-enter the password for verification 


The upgrade logs are located in the /tmp/novell_access_manager/ directory. The logs have 
time stamping. 


9.1.1.4 Upgrading Access Gateway Service 


Perform the steps provided in “Upgrading Access Gateway Service” on page 109. 


9.1.2 Upgrading Access Manager 


You must be on Access Manager 4.1 SP2 or a higher version to upgrade to latest version. 
For upgrading, you need to upgrade the components in the following order: 


¢ Section 9.1.2.1, “Upgrading Administration Console,” on page 105 

¢ Section 9.1.2.2, “Upgrading Identity Server,” on page 106 

¢ Section 9.1.2.3, “Upgrading Access Gateway Appliance,” on page 108 
¢ Section 9.1.2.4, “Upgrading Access Gateway Service,” on page 109 


When you are upgrading the components, take care of the following points: 


+ Ensure that you are on Access Manager 4.1 SP2 or a higher version. For more information about 
the supported upgrade path, see Chapter 9, “Upgrading Access Manager,” on page 101. 
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+ You must backup the files that you have customized. 
+ Ensure that you follow the procedure given below for both Linux and Red Hat: 


1 Open the nds.conf file available under /etc/opt/novell/eDirectory/conf/. 


2 Delete all the duplicate lines from the file. For example the file may contain two lines of 
n4u.server.vardir=/var/opt/novell/eDirectory/data. Delete one of them. 


3 Restart eDirectory using /etc/init.d/ndsd restart command. 


NOTE: If you have enabled history for risk-based authentication in a prior version of Access Manager, 
you must upgrade the database for risk-based authentication after upgrading to 4.3. You can find the 
upgrade script here: /opt/novell/nids/1ib/webapp/WEB-INF/RiskDBScript . Zip. 


MySQL: Run netiq_risk_mysql_upgrade.sql 
Oracle: Run netigq_risk_oracle_upgrade.sql 


Microsoft SQL Server: Run netiq_risk_sql_server_upgrade.sql 


Upgrading Administration Console 


NOTE: Access Manager by default supports Tomcat 8.0.35 and OpenSSL 1.0.2). Due to this, Identity 
Server and Access Gateway disable requests from clients that are on versions lower than TLS1. 
However, Access Gateway can continue communication with web servers that are on versions lower 
than TLS1. 


If Identity Server is installed on the same machine as Administration Console, Identity Server is 
automatically upgraded with Administration Console. If you are upgrading this configuration and you 
have custom JSP pages, you can backup these files or allow the upgrade program to back them up 
for you. 

1 Back up any customized JSP pages and related files. 


Even though the upgrade program backs up the JSP directory and its related files in the /root/ 
nambkup folder, it is a good practice to backup these files. 


/var/opt/novell/tomcat/webapps/nidp/jsp 
2 Open a terminal window. 
3 Log in as the root user. 


4 Download the upgrade file from dl.netiq.com and extract the tar.gz file using the following 
command: tar -xzvf <filename>. 


NOTE: For information about the name of the upgrade file, see the specific Release Notes on 
the Access Manager Documentation website. 


5 Change to the directory where you unpacked the file, then enter the following command in a 
terminal window: 


./upgrade.sh 


6 The system displays the confirmation message along with the list of installed components. For 
example, if the Administration Console and Identity Server are installed on the same machine, 
the following message is displayed: 
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The following components were installed on this machine 


1. Access Manager Administration Console 
2. Identity Server 
Do you want to upgrade the above components (y/n)? 


Type Y and press Enter. 


The system displays a warning message because the latest version of Access Manager uses 
stronger TLS protocols, ciphers, and other security settings. 


Type Y to continue with the upgrade, then press Enter. 

If you do not want to include the security configurations, then type n. This stops the upgrade. 
Enter the Access Manager Administration Console user ID. 

Enter the Access Manager Administration Console password. 

Re-enter the password for verification. 

The system displays the following message when the upgrade is complete: 


Upgrade completed successfully. 


(Optional) To view the upgrade files: 
+ To view the upgrade log files, see the files in the /tmp/novell_access_manager directory. 


+ If you selected to back up your configuration and used the default directory, see the zip file 
in the /root/nambkup directory. The log file for this backup is located in the /var/log 
directory. 


+ Ifthe Identity Server is installed on the same machine, the JSP directory was backed up to 
the /root/nambkup directory. The file is prefixed with nidp_jps and contains the date and 
time of the backup. 


NOTE: If you have customized the Java settings in the /opt/novell/nam/idp/conf/tomcat .conf 
file, then after the upgrade, you must copy the customized setting to the new file. 


If you encounter an error, see Section 13.3, “Troubleshooting Linux Administration Console 
Upgrade,” on page 137. 


Upgrading Identity Server 


Use the following procedure to upgrade stand-alone Identity Server. If you have installed both Identity 
Server and Administration Console on the same machine, see “Upgrading Administration Console” 
on page 105. 


IMPORTANT: Ensure to complete the following actions before you begin: 


+ If you are upgrading Access Manager components on multiple machines, ensure that the time 


and date are synchronized on all machines. 


+ Make sure that Administration Console is running. However, you must not perform any 


1 


configuration tasks in Administration Console during an Identity Server upgrade. 


Back up any customized JSP pages and related files. 


Even though the upgrade program backs up the JSP directory and its related files in the /root/ 
nambkup folder, it is a good practice to backup these files. 


2 Open a terminal window. 
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Download the upgrade file from dl.netiq.com and extract the tar .gz file using the following 
command: tar -xzvf <filename>. 


NOTE: For information about the name of the upgrade file, see the specific Release Notes on 
the Access Manager Documentation website. 


Change to the directory where you unpacked the file, then enter the following command in a 
terminal window: 


./upgrade.sh 
The system displays the following confirmation message: 


The following components were installed on this machine 
1. Identity Server 


Do you want to upgrade the above components (y/n)? 


Type Y and press Enter. 


The system displays two warning messages. The first message is for backing up all JSPs before 
proceeding with the upgrade, and the next is for including security settings. 


Type Y to continue with the upgrade, then press Enter. 

If you do not want to include the security configurations, then type n. This stops the upgrade. 
Enter the Access Manager Administration Console user ID. 

Enter the Access Manager Administration Console password. 

Re-enter the password for verification. 

The system displays the following message when the upgrade is complete: 


Upgrade completed successfully. 


Restore any customized files from the backup taken earlier. To restore files, copy files to the 
respective locations: 
+ /opt/novell/nam/idp/webapps/nidp/jsp 
+ /opt/novell/nam/idp/webapps/nidp/html 
+ /opt/novell/nam/idp/webapps/nidp/images 
+ /opt/novell/nam/idp/webapps/nidp/config 
+ /opt/novell/nam/idp/webapps/nidp/WEB- INF/1ib 
+ /opt/novell/nam/idp/webapps/nidp/WEB- INF/web. xml 
+ /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes 
+ /opt/novell/nam/idp/webapps/nidp/WEB- INF/conf 
+ /opt/novell/java/jre/lib/security/bcslogin.conf 
+ /opt/novell/java/jre/lib/security/nidpkey. keytab 
+ /opt/novell/nids/lib/webapp/classUtils 
+ /opt/novell/nam/idp/conf/server . xml 


Also, add the following line to the server.xml file: 
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<Connector NIDP_Name="localConnector" URIEncoding="utf-8" 
acceptCount="100" address="127.0.0.1" connectionTimeout="20000" 
maxThreads="600" minSpareThreads="5" port="8088" protocol="HTTP/1.1" /> 


An example below shows that the IP address is removed and ciphers added.<Connector 
NIDP_Name="connector" port="8443" address="" 
Cciphers="SSL_RSA_WITH_RC4_128 MD5, SSL_RSA_WITH_RC4_128 SHA, ... ../> 


+ /opt/novell/nam/idp/conf/tomcat .conf 


NOTE: If you are using Kerberos and you have renamed nidpkey. keytab and bcsLogin.conf with 
any other name, ensure that you modify the upgrade_utility_functions.sh script located in the 
novell-access-manager -x.x.x.x-xxx/scripts folder with these names before upgrading Access 
Manager. 


NOTE: If you have customized the Java settings in the /opt/novell/nam/idp/conf/tomcat .conf 
file, then after the upgrade, you must copy the customized setting to the new file. 


NOTE: If you have modified the JSP file to customize the login page, logout page, and error 
messages, you can restore the JSP file after installation. You should sanitize the restored JSP file to 
prevent XSS attacks. For more information, see Preventing Cross-site Scripting Attacks in the NetIQ 
Access Manager 4.3 Administration Guide. 


Upgrading Access Gateway Appliance 


Prerequisite: If you are on an older version of Access Manager, before upgrading to 4.3, you must 
first upgrade the base operating system of Access Gateway Appliance to the latest operating system 
that is included in the 4.3 Access Gateway appliance ISO. For more information about how to 
upgrade, see Chapter 10, “Upgrading the Operating System for Access Gateway Appliance,” on 
page 119. 


1 Back up any customized JSP pages and related files. 


Even though the upgrade program backs up the JSP directory and its related files in the /root/ 
nambkup folder, it is a good practice to backup these files. 


2 Open a terminal window. 
3 Log in as the root user. 


4 Download the upgrade file from dl.netiq.com and extract the tar.gz file using the following 
command: tar -xzvf <filename>. 


NOTE: For information about the name of the upgrade file, see the specific Release Notes on 
the Access Manager Documentation website. 


5 Change to the directory where you unpacked the file, then enter the following command in a 
terminal window: 


./ma_upgrade.sh 


6 Awarning message regarding backup and restore is displayed followed by the message for 
including security settings. 
If you have customized any files, take a backup and restore them after installation. 

7 Would you like to continue this upgrade? Type Y to continue. 
If you do not want to include the security configurations, then type n. This stops the upgrade. 
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8 Do you want to restore custom login pages? Type Y to confirm. 
9 Enter the Access Manager Administration Console user ID. 
10 Enter the Access Manager Administration Console password 
11 Re-enter the password for verification 
12 The system displays the following message when the upgrade is complete: 


Upgrade completed successfully. 


13 Restore any customized files from the backup taken earlier. To restore the files, copy the files to 
the respective locations below: 


+ /opt/novell/nam/mag/webapps/ 
nesp/WEB- INF/web. xml 

+ /opt/novell/nam/mag/webapps/ 
nesp/jsp 

+ /opt/novell/nam/mag/webapps/ 
nesp/html 

+ /opt/novell/nam/mag/webapps/ 
nesp/images 

+ /opt/novell/nam/mag/webapps/agm/WEB- INF/ 
config/current 

+ /opt/novell/nam/mag/webapps/ 
nesp/config 

+ /opt/novell/devman/jcc/scripts/ 
presysconfig.sh 

+ /opt/novell/devman/jcc/scripts/ 


postsysconfig.sh 


9.1.2.4 Upgrading Access Gateway Service 


+ “Prerequisites for Access Gateway Service” on page 109 


+ “Process” on page 109 


Prerequisites for Access Gateway Service 


+ Manually back up the tomcat.conf and the server.xml files from /opt/novell/nam/ 
mag/conf. 


The ag_upgrade.sh script takes care of backing up the remaining customized files 
automatically. These files get automatically backed up at the /root/nambkup folder and includes 
apache configuration and error pages. 


Process 


1 Download the AM_43_AccessGatewayService_Linux_64.tar.gz file from the NetIQ download 
site and extract it by using the following command: 
tar -xzvf <AM_43_AccessGatewayService_Linux_64.tar.gz> 


2 Run the ag_upgrade.sh script from the folder to start the upgrade. 
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3 Specify the following information: 


User ID: Specify the name of the administration user for the Administration Console. 


Password and Re-enter Password: Specify and re-enter the password for the administration user 
account. 


The Access Gateway Service is upgraded. The following message is displayed when upgrade is 
complete: 


Starting Access Manager services... 
Backup of customized files are available at /root/nambkup. Restore them if 
required. 


View the log files. The install logs are located in the /tmp/novell_access_manager/ directory. 


5 Restore any customized files from the backup taken earlier as part of steps in “Prerequisites for 


Access Gateway Service” on page 109. 


To restore the files, copy the content of the following files to the corresponding file in the new 
location. 


Old File Locations New File Location 


/root/novell_access_manager/apache2/ /opt/novell/apache2/share/apache2/error 
(contains apache var files) 


/root/novell_access_manager/nesp/ /var/opt/novell/tomcat/webapps/nesp/jsp/ 
(contains modified error pages) 


server.xml: 


If you have modified any elements or attributes in the 4.1.x or 4.2 environment the corresponding 
changes will need to be applied to the 4.3 server.xml file. 


Typical changes done to the server.xml include modifying the 'Address=' to restrict the IP 
address the application will listen on, or 'maxThreads=' attributes to modify the number of 
threads. 


In the following example, 4.1.x has customized maxThreads value. 


<<Connector port="9009" enableLookups="false" redirectPort="8443" 
protocol="AJP/1.3" address="127.0.0.1" minSpareThreads="25" maxThreads="700" 
backlog="0" connectionTimeout="20000, ... ../> 


Make a note of the customizations and copy paste the changed values in the 4.3 server.xml] file 
tomcat.conf: 


Copy any elements or attributes that you have customized in the tomcat7.conf file to the 
tomcat .conf file. 


For example, if you have included the environment variable to increase the heap size by using - 
Xmx/Xms/Xss attributes in the tomcat7.conf file, copy this variable to the 4.3 /opt/novell/ 
nam/idp/conf/tomcat .conf file. 


Modify the required properties in /opt/novell/nam/mag/webapps/agm/WEB- INF/ 

agm. properties using back up file /root/novell_access_manager/agm/agm. properties. If 
you have customized the agm. properties file from the backup taken in 3.2.x, 4.0.x or 4.1.x, 
ensure that you apply the same to the new 4.3 /opt/novell/nam/mag/webapps/agm/WEB- INF/ 
agm. properties file. An example below shows the how to enable the backend webserver's 
webpage caching and the cache location. 


apache.disk.cache.enabled=yes 


apache.disk.cache. root=/var/cache/novell-apache2 


Upgrading Access Manager 


9.2 


7 Change the ownerships of the following files (with read access to tomcat user) using the 
following commands: 


chown -R novlwww:novlwww /var/opt/novell/tomcat/webapps/nesp/jsp/ 


chown -R novlwww:novlwww /opt/novell/nam/mag/webapps/agm/WEB- INF/ 
agm.properties 


8 On the newly added Access Gateway Service, restart Tomcat using the /etc/init .d/novell- 
mag restart or rcnovell-mag restart command. 


NOTE: If you have customized the Java settings in the /opt/novell/nam/idp/conf/tomcat.conf file, then 


after the upgrade, you must copy the customized setting to the new file. 


Upgrading Analytics Server 


To upgrade Analytics Server, perform the following on Analytics Server: 


1 Log in to the Server as a root user. 


2 Download the upgrade file and extract the tar.gz file using the following command: 


tar -xzvf <filename> 


NOTE: For information about the name of the upgrade file, see the specific Release Notes on 
the Access Manager Documentation website. 


3 Change to the directory where you unpacked the file, then enter the following command in a 
terminal window: 


./ar_upgrade.sh 


4 Specify the following details: 


+ 


Enter the Access Manager Administration Console user ID: Enter the Access Manager 
Administration Console administrator's ID. By default, it is admin. 


Enter the Access Manager Administration Console password: Enter the Access 
Manager Administration Console administrator's password. 


Re-enter the password for verification: Re-enter the Access Manager Administration 
Console administrator's password. 


Enter the Access Manager Analytics Server administrator password: Enter the 
Analytics Server administrator's password. You use this password for logging in to Analytics 
Server, and the Reporting console. 


Re-enter the password for verification: Re-enter the Analytics Server administrator's 
password. 


The upgrade completes with the following options. Choose one of the following options: 


¢ Delete the existing aggregated data from elasticsearch 


e Migrate the existing aggregated data to a new data schema.(This may take longer time) 


By default, the data is migrated. The migration of data may take longer time. If it fails, you must run 
the upgrade script again. Even when the data from the elasticsearch is deleted, the audit data is not 
deleted from the server. 
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The upgrade logs are saved in the /tmp/novell_access_manager/ directory. The logs include time 
stamping. 


NOTE: After upgrading Analytics Server, you must clear the browser cache before accessing 
Analytics dashboard. 


9.3 Upgrading Analytics Server in a High Availability 


Setup 


You must first upgrade the passive node in the cluster, then upgrade the active node. 
1 Enable the maintenance mode on the cluster. 
crm configure property maintenance-mode=true 


Maintenance mode helps you to avoid any disturbance to the running cluster resources when 
you update Analytics Server. You can run this command from any cluster node. 


2 Verify if the maintenance mode is active. 
crm status 
The cluster resources should appear in the unmanaged state. 
3 Upgrade the passive cluster node: 
3a Stop the cluster stack. 
rcopenais stop 


Stopping the cluster stack ensures that the cluster resources remain accessible and avoids 
fencing of nodes. 


3b Upgrade Analytics Server on the passive node. For information about upgrading Analytics 
server, refer “Upgrading Analytics Server” on page 111. 


3c After the upgrade is complete, start the cluster stack. 
rcopenais start 


4 Upgrade the active cluster node: 
4a Stop the cluster stack. 
rcopenais stop 


Stopping the cluster stack ensures that the cluster resources remain accessible and avoids 
fencing of nodes. 


4b Upgrade Analytics Server on the active node. For information about upgrading Analytics 
server, refer “Upgrading Analytics Server” on page 111. 


4c After the upgrade is complete, start the cluster stack. 
rcopenais start 


4d Run the csync2 -x -v command to synchronize any changes in the configuration files. 
5 Disable the maintenance mode on the cluster. 


crm configure property maintenance-mode=false 


You can run this command from any cluster node. 
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9.4.2 


9.4.3 


6 Verify whether the maintenance mode is inactive. 
crm status 


The cluster resources should appear in the Started state. 


Upgrading Access Manager on Windows 


¢ Section 9.4.1, “Prerequisites,” on page 113 
¢ Section 9.4.2, “Upgrading the Evaluation Version to the Purchased Version,” on page 113 


¢ Section 9.4.3, “Upgrading Access Manager,” on page 113 


Prerequisites 


In addition to the following prerequisites, ensure that you also meet the hardware requirements. For 
more information about hardware requirements, see the component-specific requirements in Part |, 
“Installing Access Manager,” on page 11. 


© Before upgrading, back up your configuration using the ambkup. bat file. For instructions, see 
Backing Up the Access Manager Configuration in the NetIQ Access Manager 4.3 Administration 
Guide. 


If the upgrade fails, you need a way to recover your configuration. As a backup can be restored 
to only the version on which it was created, you must restore your Access Manager components 
to that version. You can then restore the configuration with the backup file and work with NetlQ 

Technical Support to solve the upgrade problem before attempting to upgrade again. 


Upgrading the Evaluation Version to the Purchased Version 


If you have downloaded the evaluation version and want to keep your configuration after purchasing 
the product, you need to upgrade each of your components with the purchased version. The upgrade 
to the purchased version automatically changes your installation to a licensed version. 


After you have purchased the product, log in to the Novell Customer Center (http:/Avww.novell.com/ 
center) and follow the link that allows you to download the product. Then follow the instructions in 
Section 9.4.3, “Upgrading Access Manager,” on page 113 for upgrading components. 
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Log in to the NetIQ Downloads page and follow the link that allows you to download the product. 


¢ Section 9.4.3.1, “Upgrading Administration Console,” on page 114 
¢ Section 9.4.3.2, “Upgrading Identity Server,” on page 115 
¢ Section 9.4.3.3, “Upgrading Access Gateway Service,” on page 117 


NOTE: If you have enabled history for risk-based authentication in a prior version of Access Manager, 
you must upgrade the database for risk-based authentication after upgrading to 4.3. You can find the 
upgrade script here: C:\Program Files\(x86)\Novell\Tomcat \webapps\nidp\WEB- 
INF\RiskDBScript. zip. 


MySQL: Run netiq_risk_mysql_upgrade.sql 
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Oracle: Run netigq_risk_oracle_upgrade.sql 


Microsoft SQL Server: Run netiq_risk_sql_server_upgrade.sql 


12 


Upgrading Administration Console 


If you have installed Administration Console and Identity Server on the same server, you must 
upgrade both of them at the same time. 


1 Manually back up your current Access Manager configuration using ambkup. bat file. For 
instructions, see Back Up and Restore in the NetIQ Access Manager 4.3 Administration Guide. 


2 Ifthe Identity Server is installed on the same server, manually back up the JSP pages and 
related files in the C:\Program Files (x86)\Novell\Tomcat\webapps\nidp\jsp directory. 


3 If you have customized the tomcat . conf file or the server.xml file, back up these files before 
upgrading. These files are overwritten during the upgrade process. 


IMPORTANT: We recommend that you have your own backup of customized files. 


4 Run the installation program. When the installation program detects an installed version of the 
Administration Console, it automatically prompts you to upgrade. 


Read the Introduction, then click Next. 
Accept the License Agreement, then click Next. 
Select the component to upgrade that is currently installed, then click Next. 


© N O 


Type Y and press Enter. 


The system displays an information message to enable Syslog on the Auditing user interface of 
the Administration Console after the upgrade. 


9 Type Y to continue with the upgrade, then press Enter. 


10 At the upgrade prompt, click Continue. 
11 Specify the following information for the administrator account on the Administration Console: 


Administration user ID: Specify the name of the administration user for the Administration 
Console. 


Password and Re-enter Password: Specify and re-enter the password for the administration 
user account. 


Decide whether you want the upgrade program to create a backup of your current configuration: 


+ If you have a recent backup, click Continue. If you choose to not create a backup when you 
do not have a recent backup and you then encounter a problem during the upgrade, you 
may be forced to re-create your configuration. 


+ If you do not have a recent backup, click Run Config Backup. The program creates a 
backup and stores it in the root of the operating system drive in the nambkup directory. 


13 Review the summary, then click Install. 
14 If the upgrade seems to hang and you have been performing other tasks on the desktop, click 


the installation screen and check for a warning message. Some subcomponents of Access 
Manager do not send warning messages to the Installation screen when the focus of the mouse 
is not on the installation window. 


15 When you are prompted, reboot the server. 
16 View the upgrade log file found in the following location: 


C:\Program Files(x86)\Novell\log\AccessManagerServer_InstallLog.1log 


114 Upgrading Access Manager 


17 Ifthe Identity Server installed on the same server, copy any custom login pages to the 
C:\Program Files (x86)\Novell\Tomcat\webapps\nidp\jsp directory. 


18 Restore any customized files from the backup taken earlier. 


To restore the files, copy the content of the following files to the corresponding file in the new 
location. 


server.xml 


If you have customized the server.xml file from the backup taken in 3.2 SP3, 4.0.x or 4.1.x, 
ensure that you apply the same to the new 4.1 server.xml located at C:\Program Files 
(x86 )\Novell\Tomcat\conf\ directory. 


An example below shows that the IP address is removed and ciphers added.<Connector 
NIDP_Name="Cconnector" port="8443" address="" 
Cciphers="SSL_RSA_WITH_RC4_128 MD5, SSL_RSA_WITH_RC4_128 SHA, ... ../> 


Tomcat properties: 


Go to C:\Program Files\Novell\Tomcat\bin. Click the tomcat 7w or the tomcat 8w file, and 
make a note of any elements or attributes customized in 4.1.x or 4.2.x respectively. 


On the 4.3 server, go to C:\Program Files\Tomcat\bin\tomcat8w. Change the values and 
attributes as required. 


9.4.3.2 Upgrading Identity Server 


If you have installed only Identity Server on the server, use the following procedure to upgrade 
Identity Server. 


1 Manually back up the JSP pages and related files in the C:\Program Files 
(x86 )\Novell\Tomcat \webapps\nidp\jsp directory. 


IMPORTANT: We recommend that you have your own backup of the customized files. 


2 If you have customized the tomcat .conf file or the server.xml file at C:\Program Files 
(x86 )\Novell\Tomcat\conf\, back up these files before upgrading. The registries and the file 
are overwritten during the upgrade process. 


3 Download and run AM_43_AccessManagerService_Win64. exe file from NetIQ. 


This file starts the installation program. When the program detects an installed version of the 
Identity Server, it automatically prompts you to upgrade. 


On the Introduction page, click Next. 
Accept the License Agreement. 
At the upgrade prompt, click Continue. 


NO on fF 


Type Y and press Enter. 

The system displays an information message to enable Syslog after the upgrade. 
8 Type Y to continue with the upgrade, then press Enter. 

9 Specify the following information for the Administration Console: 


Administration user ID: Specify the name of the administration user for the Administration 
Console. 


Password and Re-enter Password: Specify and re-enter the password for the administration 
user account. 
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If you have customized login pages, decide whether you want your customized pages restored 
automatically. Be aware that any new feature introduced in the JSP files that have the same 
name as your files are lost when your file overwrites the installed file with the automatic restore. 


You may want to wait until after the upgrade, then compare your customized file with the newly 
installed file. You can then decide whether you need to modify your file before restoring it. 


NOTE: Ensure that you sanitize the restored customized JSP file to prevent XSS attacks. For 
more information about how to sanitize the JSP file, see Preventing Cross-site Scripting Attacks 
in the NetIQ Access Manager 4.3 Administration Guide. 

Review the summary, then click Install. 

View the upgrade log file found in the following location: 

C:\Program Files (x86)\Novell\log\AccessManagerServer_ InstallLog.1log 


Copy any custom login pages to the C:\Program Files 
(x86) \Novell\Tomcat \webapps\nidp\jsp directory. 


Restore any customized files from the backup taken earlier. 


To restore the files, copy the content of the following files to the corresponding file in the new 
location. 


server.xml 


If you have customized the server. xml file from the backup taken in 3.2 SP3, 4.0.x, or 4.1.x, 
ensure that you apply the same to the new server.xml located at C:\Program Files 
(x86 )\Novell\Tomcat\conf\ directory. 


Also, add the following line to the server.xml file to use the new features on the user portal: 


<Connector NIDP_Name="localConnector" URIEncoding="utf-8" acceptCount="100" 
address="127.0.0.1" connectionTimeout="20000" maxThreads="600" 
minSpareThreads="5"_ port="8088" protocol="HTTP/1.1" /> 


An example below shows that the IP address is removed and ciphers added.<Connector 
NIDP_Name="connector" port="8443" address="" 
Ciphers="SSL_RSA_WITH_RC4_128 MD5, SSL_RSA_WITH_RC4_128 SHA, ... ../> 


Tomcat properties: 


Go to C:\Program Files\Novell\Tomcat\bin\tomcat7w. Double-click the tomcat7w file and 
make a note of any elements or attributes customized in 4.1.x. 


On the 4.3 server, go to C:\Program Files\Tomcat\bin\tomcat8w. Change the values and 
attributes as required. 


Restart tomcat server using the Windows service. Go to Start > Control Panel > System and 
Security > Administrative Tools > Services. 


IMPORTANT: If NetIQ Access Manager is federated with other service providers or if the users are 
redirected to Access Gateway protected resources from the Identity Server using the target_url, you 
may see errors regardless of successful authentication. The ConfigUpgrade script enables ‘Allow any 
target’ for the ‘Intersite Transfer Service’ configuration service for all the service providers. 
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9.4.3.3 Upgrading Access Gateway Service 


You can upgrade by using the same installer you used to install the product. The program detects that 
Access Gateway Service is already installed and prompts you to upgrade. 


1 
2 
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Download and run AM_43_AccessGatewayService_Win64. exe file from NetlQ. 


Run the installation program. When the installation program detects an installed version of the 
Access Gateway, it automatically prompts you to upgrade. 


Answer Yes to the prompt to upgrade. 

Read the Introduction, then click Next. 

Review the Readme information, then click Next. 

Accept the License Agreement, then click Next. 

Specify the following information: 

User ID: Specify the name of the administration user for the Administration Console. 


Password and Re-enter Password: Specify the password and re-enter the password for the 
administration user account. 


Review the installation summary, then click Install. 
Access Gateway Service is upgraded. 


View the log files. The install logs are located in the C:\Program Files\Novell\log and 
C:\agsinstall.1log directories. 


Restore any customized files from the backup taken earlier. 


To restore the files, copy the content of the following files to the corresponding file in the new 
location. 


server.xml: 


If you have customized the server . xml file from the backup taken in 4.1.x or 4.2.x, ensure that 
you apply the same to the new server.xml located at C:\Program 
Files\Novell\Tomcat\conf\ directory. 


An example below shows that the IP address is removed and ciphers added.<Connector 
NIDP_Name="connector" port="8443" address="" 
Ciphers="SSL_RSA_WITH_RC4_128 MD5, SSL_RSA_WITH_RC4_128 SHA, ... ../> 


Tomcat properties: 


Go to C:\Program Files\Novell\Tomcat\bin. Click the tomcat 7w (for 4.1.x) or the tomcat 8w 
(for 4.2.x) file and make a note of any elements or attributes that are customized. 


On the 4.3 server, go to C:\Program Files\Novell\Tomcat\bin\tomcat8w. Change the 
values and attributes as required. 


Restart the tomcat server by using the Windows service. Go to Start > Control Panel > System 


and Security > Administrative Tools > Services. 
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Upgrading the Operating System for 
Access Gateway Appliance 


Access Gateway Appliance bundles the latest SUSE kernel. During fresh installation of Access 
Gateway Appliance, the latest kernel is installed automatically. You must upgrade the base operating 
system before upgrading Access Gateway Appliance. 


NOTE: After upgrading base operating system, you also need to re-register the new channel. For 
more information, Section 10.1, “Setting Up the Channel After Upgrading Base Operating System,” 
on page 119. 


Perform the following steps to upgrade the base operating system: 


1 Get the Access Gateway 4.3 Appliance ISO and mount it in the Access Manager server where 
you want to upgrade. For example, if you want to mount on /root/iso, use the following 
command: 


mount -o loop /dev/dvd /root/iso/ 


NOTE: Create /root/iso by using the mkdir -p /root/iso command before executing the 
above command. 


2 Use the following command to add the mounted ISO as the upgrade repository: 
zypper ar /root/iso/ 43agapp 

3 Refresh the new repository by using the following command: 
zypper ref 


4 Use the following command to upgrade the base operating system from the repository you 
added: 


zypper dup --from 43agapp 


5 You will be prompted a dependency resolution for open-iscsi and crash-sial-6.0.7- 
0.10.1.x86_64. Select 1 from the solutions. 


6 Accept the license. The operating system will start upgrading. 
7 After upgrade, view the notification. 
8 Restart Access Gateway Appliance. 


10.1 Setting Up the Channel After Upgrading Base 
Operating System 
You must set up the channel if the base operating system is upgraded. If you had an existing channel 


for an older version of Access Manager and SLES operating system, then after upgrading to the 
latest operating system and Access Manager 4.3, you must re-register the new channel. 


NOTE: If you are upgrading from Access Manager 4.2 and you have already set up the 4.2 channel, 
then you do not require to re-register the channel for 4.3. 
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Perform the following steps to set up the SLES 11 SP4 channel. 


1 


Upgrade the base Operating System to SLES 11 SP4. For more information about upgrading the 
base operating system, see Section 10, “Upgrading the Operating System for Access Gateway 
Appliance,” on page 119. 


Upgrade the Access Gateway Appliance. 


3 If the version mentioned in the /etc/products.d/NAM_APP.prod file is other than 4.2, edit the 


file and change the version to 4.2. The line will look like the following: 
<version>4.2</version> 

Remove all the old NCC credentials using the following commands: 

rm /etc/zypp/credentials.d/NCCcredentials 

rm /etc/zypp/repos.d/nu* 

rm /etc/zypp/services.d/nu* 

Use the zypper lr command to verify that the old channel is removed. 


Re-register to get the latest updates. For more information, see Section 11.1, “Installing or 
Updating Security Patches for the Access Gateway Appliance and Analytics Server,” on 
page 121. 


Use the zypper lr command to verify if the new channel NAM42-APP-Updates is added. 
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11.1 


11.1.1 


Getting the Latest Security Patches 


The OpenSSL open source project team regularly releases updates to known OpenSSL 
vulnerabilities. Access Gateway and Analytics Server use the OpenSSL library for cryptographic 
functions. It is recommended that you keep Access Gateway and Analytics Server updated with the 
latest OpenSSL patch. 


Prerequisites 


O Before upgrading the kernel, ensure that you have updated the operating system to a supported 
version. 


O Access Gateway Appliance and Analytics Server install a customized version of SLES 11 SP4. 
If you want to install the latest patches as they become available, you must have a user account 
to receive the Linux updates. 


O Ensure that you have obtained the activation code for Access Manager from Novell Customer 
Center. 


WARNING: Installing additional packages other than security updates breaks your support 
agreement. If you encounter a problem, Technical Support can require you to remove the additional 
packages and to reproduce the problem before receiving any help with your problem. 


¢ Section 11.1, “Installing or Updating Security Patches for the Access Gateway Appliance and 
Analytics Server,” on page 121 


¢ Section 11.2, “Updating Security Patches for Access Gateway Service,” on page 124 


Installing or Updating Security Patches for the 
Access Gateway Appliance and Analytics Server 


To get the latest security updates for Access Gateway Appliance and Analytics Server, you can follow 
any of these options: 


e Section 11.1.1, “Registering to Novell Customer Center,” on page 121 
¢ Section 11.1.2, “Configuring Subscription Management Tool,” on page 123 


Registering to Novell Customer Center 


To get the latest security updates for Access Gateway Appliance and Analytics Server, the user must 
register with the Novell Customer Center by using the activation code obtained with the product: 


NOTE: You must perform the proceeding steps to register with Novell Customer Center for Access 
Gateway Appliance and Analytics Server separately. 
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If you face issues while using the activation code to register, see TID 3303599. 


Go to YaST > Support > Novell Customer Center Configuration. 


Select Configure Now (Recommended). In addition to the options that are selected by default, 
select Registration Code. 


Click Next. 


The Manual Interaction Required screen appears. It might take a few minutes to connect to the 
server. 


This screen indicates that to activate the product, you must provide a valid e-mail ID associated 
with the Novell account and the activation code. 


4 Click Continue. 


5 To specify the e-mail address, activation code, and system name in the relevant fields: 


on O 
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5a Select the relevant option, then press Enter. A text field appears in the bottom left corner of 
the screen. 


5b Specify value for the selected option in this text field, then press Enter to return to the 
screen. 


5c Repeat these steps for each field. 
Click Submit after you have specified all the relevant information to complete the registration. 
Enter Q to close the window. 
Enter Y at the prompt. 
The Manual Interaction Required screen is displayed. It indicates that the software repositories 


are created. You will receive a message from the Novell Customer Center Configuration 
indicating that the configuration was successful. 


Click OK to return to YaST Control Center. 
Click Quit to exit YaST. 


Open a shell prompt and specify the following command to verify if the repository named NAM4x- 
APP-Updates was created: 


zypper 1r 


An output similar to the following appears: 
Access Gateway Appliance 


# | Alias | Name 

| Enabled | Refresh 

Sethe a cece cee asec oat eee cee occ E E ca ee Ape Sia chet ers ers siete ace aise eet ee Sia eee eeja ease 
1 | NetIQAccessGatewayAppliance-4.x.x-x | NetIQAccessGatewayAppliance-4.x.x-x 
| Yes | No 

2 | nu_novell_com:NAM4x-APP-Updates | NAM4x-APP-Updates 

| Yes | Yes 


Analytics Server 


# | Alias | Name 

| Enabled | Refresh 

Slee eee oie es eee Soha a tans ce aie eae Seo are apa a E S.arote ans Sse eset esi bee ecole Spee Sieje ios] 
1 | NetIQAnalyticsServer-4.x.x-x | NetIQAnalyticsServer-4.x.x-x 

| Yes | No 

2 | nu_novell_com:NAM4x-APP-Updates | NAM4x-APP-Updates 

| Yes | Yes 
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11.1.2.2 


12 Run the zypper up command to install the patches 
13 After the patches are installed, restart the machine. 
14 Confirm that all the patches are installed by running zypper up command again. 


Configuring Subscription Management Tool 


You can register Access Gateway Appliance and Analytics Server to local Subscription Management 
Tool (SMT) server and download software updates from there instead of communicating directly with 
the Novell Customer Center and the NU servers. 


To use an SMT server for client registration and as a local update source, you must configure the 
SMT server in your network first. The SMT server software is distributed as an add-on for SUSE 
Linux Enterprise Server. For information about configuring the SMT server, see Subscription 
Management Tool (SMT) for SUSE Linux Enterprise 11. 


The following sections describe the configuration required for Access Gateway Appliance: 


¢ Section 11.1.2.1, “SMT Configuration,” on page 123 
¢ Section 11.1.2.2, “Configuring Access Gateway Appliance and Analytics Server,” on page 123 


SMT Configuration 


You must configure the SMT server and set up subscription for NAM4x-APP-Updates channel to 
receive the updates for Access Gateway Appliance and Analytics Server. 


1 Install the SMT server in a SLES 11 SP4 Server. For more information, see Subscription 
Management Tool (SMT) for SUSE Linux Enterprise 11. 

Log in to you Novell Customer Center account. 

Select My Products > Mirroring Credentials, then click Generate Credentials. 

Copy the mirroring credentials before logging out of your Novell Customer Center account. 
Run the SMT Configuration tool from YAST, then specify the mirroring credentials. 


ao a fF WO ND 


Run the SMT Management tool. 
The NAM4x-APP-Updates, sle-11-x86_64 repository is displayed in the Repositories tab. 


7 Select sle-11-x86_64, then click Toggle Mirroring to ensure mirroring is selected for this 
repository. 


8 Click Mirror Now. This step ensures that the NAM4x-APP-Updates channel updates are 
mirrored from nu.novell.com to your local SMT server. 


9 When mirroring is complete, click OK to close the tool. 


Configuring Access Gateway Appliance and Analytics Server 


1 Copy /usr/share/doc/packages/smt/clientSetup4SMT.sh from the SMT server to the client 
machine. 


You can use this script to configure a client machine to use the SMT server or to reconfigure it to 
use a different SMT server. 


2 Specify the following command as root to execute the script on the client machine: 
./clientSetup4SMT.sh --host server_hostname 


For example, 
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./clientSetup4SMT.sh --host smt.example.com. 


You can get the SMT server URL by running the SMT Configuration tool at the server. The URL 
is set by default. 

Enter y to accept the CA certificate of the server. 

Enter y to start the registration. 

The script performs all necessary modifications on the client. 
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Execute the following command to perform registration: 

suse_register 

7 Specify the following command to get online updates from the local SMT server: 
zypper up 

8 Reboot the machine if prompted at the end of any patch install. 

9 Confirm that all the patches are installed by running zypper up command again. 


11.2 Updating Security Patches for Access Gateway 
Service 


¢ Updating Linux Access Gateway Service with the Latest OpenSSL Patch 
¢ Updating Windows Access Gateway Service with the Latest OpenSSL Patch 


11.2.1 Updating Linux Access Gateway Service with the Latest 
OpenSSL Patch 


1 Download the openssl-update.sh script. 

2 Change the file permission to executable: 
chmod +x openssl-update.sh 

3 Run the following command: 


openssl-update.sh username password novell-nacm-apache-extra-4.0.8-1.0.2g' 


NOTE: This downloads the 1.0.2) version of OpenSSL. Change the version number depending 
on the version available on the appliance channel. 


username and password are the mirror credentials for the Novell Customer Care Portal the 
product is registered with. 


11.2.2 Updating Windows Access Gateway Service with the Latest 
OpenSSL Patch 


1 Open the powershell command line with the admin privilege. 
C: \Windows\System32\WindowsPowerShell\v1.0\powershell.exe 


2 Navigate to C:\Program Files\Novell\bin, then run patch_update.ps1 with the following 
three arguments: 


+ username 
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+ password 
+ rpmfilename (the RPM file name should not be suffixed with .rpm) 


Here username and password are the mirror credentials for the Novell Customer Care Portal the 
product is registered with, and the rpmfilename is the version of OpenSSL you are upgrading to. 
This version includes the OpenSSL version in the string. For example, 


patch_update.psi1 <myusername> <mypassword> <Openssl_Win_102j> 


NOTE: You must repeat these steps for all the Windows Access Gateway servers. 
This command updates to OpenSSL 1.0.2). 


The local download location for the OpenSSL update is C:\Program 
Files\Novell\apache\novell_patch. 
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| | Troubleshooting Installation and 
Upgrade 


¢ Chapter 12, “Troubleshooting Installation,” on page 129 
+ Chapter 13, “Troubleshooting Upgrade,” on page 137 
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2 Troubleshooting Installation 


¢ Section 12.1, “Troubleshooting a Windows Administration Console Installation,” on page 129 

¢ Section 12.2, “Secondary Administration Console Installation Fails,” on page 130 

¢ Section 12.3, “Troubleshooting an Identity Server Import and Installation,” on page 130 

¢ Section 12.4, “Troubleshooting the Windows Access Gateway Service Installation,” on page 132 


¢ Section 12.5, “Access Gateway Appliance Installation Fails Due to an XML Parser Error,” on 
page 133 


¢ Section 12.6, “Troubleshooting Access Gateway Import,” on page 133 

¢ Section 12.7, “Troubleshooting the Uninstall of Access Gateway Service,” on page 135 

¢ Section 12.8, “Troubleshooting the Uninstall of Windows Identity Server,” on page 135 

¢ Section 12.9, “Installing RHEL on Administration Console Fails if IPv6 Is Disabled,” on page 136 


12.1 Troubleshooting a Windows Administration 
Console Installation 


The following instructions explain how to run the installation program in debug mode and how to 
clean up after such an installation: 


1 Use the following command to start the installation program: 
<filename>.exe -DAM_INSTALL_DEBUG=true -DAM_INSTALL_DEBUG_JAVA=true 


Replace <filename> with the name of the executable. 

2 Press the Ctrl key until the progress bar reaches 100% and goes away. 
A terminal window opens to display standard output. 
Additional verbose information is sent to the \am32setup_debug. txt file. 

3 Use the output and the log file to discover the cause of the problem. 

4 After you run the installation in debug mode, you must clean up the results: 
4a Delete the temporary packages in the \pkgdirs directory, then delete the directory. 
4b Delete the \am32setup_debug.txt file. 
4c Delete the installation log files in the following directories: 

Windows 2012 Server: \am32setup.log 
Windows 2012 Server: \Program Files (x86)\Novell\log 


IMPORTANT: You need to delete the log files because they contain sensitive information in 
clear text. 
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Secondary Administration Console Installation 
Fails 


Secondary Administration Console installation fails with a message “Verifying time synchronization”. 
If you are installing secondary Administration Console, ensure that time is in sync with primary 
Administration Console prior to installation. 


If the time is in sync and secondary Administration Console installation fails or takes a long time, see 
the eDirectory install logs under /tmp/novell_access_manager. The log file name will be similar to 
install_edir_xxxxxx. If at the end of the log, you see an entry “Verifying time synchronization” 
multiple times, repair the eDirectory by performing the following steps: 

1 Log into primary Administration Console and execute the ndsrepair -T command. 

2 Execute the ndsrepair -N command and select the server which has the problem. 


3 Log into secondary Administration Console and you can see that the installation has proceeded. 
You need not to re-run the installer. 


Troubleshooting an Identity Server Import and 
Installation 


è Section 12.3.1, “Identity Server Fails to Import into Administration Console,” on page 130 
¢ Section 12.3.2, “Reimporting Identity Server,” on page 131 
¢ Section 12.3.3, “Check the Installation Logs,” on page 131 


Identity Server Fails to Import into Administration Console 


Check for the following points if you have installed your Administration Console and Identity Server on 
different machines: 


¢ The following ports should be opened between the machines: 


8444 
1443 
1289 
524 
636 


Identity Server firewall also needs to have ports 8080 and 8443 open between the server and the 
clients for the clients to log into Identity Server. For more information about firewalls and ports, 
see “Setting Up Firewalls” on page 29. 


+ Time needs to be synchronized between the two machines. Ensure that both machines are 
configured to use a Network Time Protocol server. 


¢ If firewalls and time synchronization do not solve the problem, run the reimport script. See 
“Reimporting Identity Server” on page 131 for instructions. 
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12.3.2 


12.3.3 


12.3.3.1 


Reimporting Identity Server 


1 
2 


Verify that Administration Console is up by logging into Administration Console. 


Verify that you can communicate with Administration Console. From the command line of Identity 
Server machine, enter a ping command with the IP address of Administration Console. 


If the ping command is unsuccessful, fix the network communication problem before continuing. 
In Administration Console, delete Identity Server. 


For more information about how to delete Identity Server in Administration Console, see Identity 
Server Advanced Configuration in the NetIQ Access Manager 4.3 Administration Guide. 


On Identity Server machine, change to the jcc directory: 
Linux: /opt/novell/devman/jcc 

Windows: \Program Files (x86\Novell\devman\jcc 
Run the reimport script for jcc: 

Linux: ./conf/reimport_nidp.sh jcc 

Windows: conf\reimport_nidp.bat jcc 

Run the reimport script for Administration Console: 
Linux: ./conf/reimport_nidp.sh nidp 

Windows: conf\reimport_nidp.bat nidp <admin> 
Replace <admin> with the name of your administrator for Administration Console. 
If these steps do not work, reinstall the device. 


Check the Installation Logs 


If Identity Server fails to install, check the installation logs. 


+ 


+ 


Section 12.3.3.1, “Linux Installation Logs,” on page 131 
Section 12.3.3.2, “Windows Installation Logs,” on page 132 


Linux Installation Logs 


Installation logs are located in the /tmp/novell_access_manager directory. Check them for warning 
and error messages. 


Table 12-1 Installation Log Files for the Linux Identity Server 


Log File Description 


inst_nids_<date&time>.log Contains the messages generated for Identity Server module. 


inst_main_<date&time>.log Contains the Tomcat messages generated during the installation. 


inst_jcc_<date&time>.log Contains the messages generated for the communications module. 


inst_audit_<date&time>.lo Contains the messages generated for the auditing components. 


g 


inst_devman_<date&time>.1 Contains the messages generated for the interaction between Identity 


og 


Server and Administration Console. 
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12.3.3.2 


12.4 


Windows Installation Logs 


Installation logs are located in the \Program Files\Novell\Tomcat\webapps \nps\WEB- 
INF\logs\install directory. Check them for warning and error messages. 


Table 12-2 Installation Log Files for the Windows Identity Server 


Log File 


basejar_InstallLog.1log 


base_InstallLog.log 


nauditjar_InstallLog.log 


nauditjar_InstallLog.1log 


NIDS_Pluginjar_InstallLog.1 
og 


NIDS_Plugin_InstallLog.log 
NMASjar_InstallLog.log 


NMAS_InstallLog.log 


Description 


Contains the messages generated when installing Identity Server JAR 
files. 


Contains the messages generated during the installation of Identity 
Server. 


Contains the messages generated when installing the Novell Audit JAR 
files. 


Contains the messages generated for the auditing components. 


Contains the messages generated when installing Identity Server plug-in 
JAR. 


Contains the messages for the plug-in component. 
Contains the messages generated when installing the NMAS JAR files. 


Contains the messages for the NMAS component. 


Troubleshooting the Windows Access Gateway 
Service Installation 


Perform the following steps: 


1 Run the following command to start the installation program: 


<filename>.exe -DAM_INSTALL_DEBUG=true -DAM_INSTALL_DEBUG_JAVA=true 


Replace <filename> with the name of the executable. 


2 Press the Ctrl key until the progress bar reaches 100% and goes away. 


Additional verbose information is sent to the \agsinstall_debug. txt file. 


3 Use the output and the log file to discover the cause of the problem. 


4 After you run the installation in debug mode, you must clean up the results: 


4a Delete the \agsinstall_debug.txt file. 


4b Delete the installation log files in the following directories: 


Windows 2012 Server: \agsinstall.log 
Windows 2012 Server: \Program Files (x86)\Novell\log 


IMPORTANT: Delete the log files because they contain sensitive information in clear text. 
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12.5 


12.6 


12.6.1 


12.6.2 


Access Gateway Appliance Installation Fails Due 
to an XML Parser Error 


This error may happen if Access Gateway Appliance is installed by using a remotely mounted 
installer. Use a locally mounted installer to avoid this issue. 


Troubleshooting Access Gateway Import 


When you install Access Gateway, it is automatically imported into Administration Console you 
specified during installation. If Access Gateway does not appear in the server list, you need to repair 
the import. 


If the repair option does not resolve the problem, refer to the information in the following sections 
explain: 

¢ Section 12.6.1, “Repairing an Import,” on page 133 

¢ Section 12.6.2, “Troubleshooting the Import Process,” on page 133 


Repairing an Import 


If Access Gateway does not appear in Administration Console within ten minutes of installing an 
Access Gateway, complete the following steps: 


1 Ifa firewall separates Administration Console and Access Gateway, ensure that the required 
ports are opened. See “When a Firewall Separates the Administration Console from a 
Component” in the NetIQ Access Manager 4.3 Installation and Upgrade Guide. 


2 Click Devices > Access Gateways. 
3 Wait for a few minutes, then click Refresh. 
4 Ifthe device import fails, a message similar to the following appears at the bottom of the table: 


Server gateway-<name> is currently importing. If it has been several minutes 
after installation, click repair import to fix it. 


5 Click repair import. 


6 If the device still does not appear or you do not receive a repair import message, continue with 
“Triggering an Import Retry” on page 134. 


7 If triggering an import retry does not solve the problem, reinstall the device. 


Troubleshooting the Import Process 


If the import process does not complete successfully, the device does not show up in Access 
Gateway list. The following sections describe the import process, where to find the log files, and how 
to use them to determine where the failure occurred. 

¢ Section 12.6.2.1, “Understanding the Import Process,” on page 134 

¢ Section 12.6.2.2, “Locating the Log Files,” on page 134 

¢ Section 12.6.2.3, “Triggering an Import Retry,” on page 134 
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12.6.2.1 Understanding the Import Process 


The following operations are performed during the import process: 


1. Auser specifies the IP address for Administration Console during installation. 


2. AJava process called “JCC” (Java Communication Channel) detects that Administration 
Console IP address/port has changed between its own configuration and the CLI-updated 
settings. 


3. An import message is sent to Administration Console, notifying it of the IP, port, and ID of Access 
Gateway. 


4. Administration Console then connects to Access Gateway device to fetch its configuration and 
version information. Access Gateway portion of the import process is now complete. 


5. As a separate asynchronous operation, the Embedded Service Provider (ESP) of Access 
Gateway connects and registers itself with the JCC. 


6. When the ESP connects to the JCC, a similar import message is sent to Administration Console 
notifying it to import into the system. 


7. Administration Console connects to the JCC, asking for the ESP configuration and version 
information. On Administration Console, an LDIF (Lightweight Directory Interchange Format) file 
containing the default configuration for the ESP is applied on the local eDirectory configuration 
store. 


8. Administration Console then makes a link between the ESP and its configuration. 


9. If the entire process completed properly, Access Gateway device appears in the list of Access 
Gateways in Administration Console. 


12.6.2.2 Locating the Log Files 


Various Access Manager components produce log files. You use the following logs on either 
Administration Console or Access Gateway. 


e Administration Console log: 
Linux: /opt/novell/devman/share/logs/app_sc.0.1log 


Windows Server 2012: \Program Files (x86)\Novell\log\app_sc.0@.1log 
e Tomcat Log on Administration Console: 

Linux: /opt/novell/nam/device name/logs/catalina. out 

The device name can be idp, mag, or adminconsole. 


Windows Server 2012: \Program Files (x86)\Novell\Tomcat\logs\stdout.log and 
\Program Files (x86)\Novell\Tomcat\logs\stderr.log 


+ JCC log on Access Gateway: 
Linux Appliance or Service: /opt/novell/devman/jcc/logs/ 


Windows Service: \Program Files\Novell\devman\jcc\logs 


12.6.2.3 Triggering an Import Retry 


1 Go to the directory: 
Linux: /opt/novell/devman/jcc/ 


Windows: \Program Files\Novell\devman\jcc 
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2 Run the following script: 
Linux: sh conf/reimport_ags.sh jcc 
Windows: conf\reimport_ags.bat jcc 
Specify details against the following prompts: 
+ Choose a local listener IP address [x.x.x.x]: 
+ (Optional) Choose a local NAT IP address [optional]: 
+ Choose Administration Console’s IP address []: 
+ Enter Admin User’s DN [cn=admin,o=novell]: 
+ Enter Admin Password: ***** 
Wait for a few minutes for the configuration to finish. 
3 Run the following script: 
Linux: sh conf/reimport_ags.sh agm 
Windows: conf\reimport_ags.bat agm <username> 
For example, if the username is admin, then run conf\reimport_ags.bat agm admin 
Specify details against the following prompts: 


¢ (Linux) Do you want to import the device with current configuration or initial configuration 
after installation (Enter C for current configuration, | for initial configuration). 


¢ (Linux) Enter Admin User's DN [cn=admin,o=novell]: 


+ Enter Admin password: 


12.7 Troubleshooting the Uninstall of Access Gateway 
Service 


When you uninstall an Access Gateway, the uninstall program prompts you for the credentials of the 
admin user for Administration Console. If the primary Administration Console is not available for the 
authentication request, the uninstall fails. 


To force the uninstall program to skip the authentication request, enter the following command: 


Linux Access Gateway Service 


/opt/novell/accessgateway/removeAccessGateway -DAM_INSTALL_AUTH_BYPASS=true 


Windows Access Gateway Service: 


\Program Files\Novell\UninstallData\remove_AccessGateway.exe -DAM_INSTALL_AUTH_ 
BYPASS=true 


12.8 Troubleshooting the Uninstall of Windows Identity 
Server 


When you uninstall a Windows Identity Server, the uninstall program prompts you for the credentials 
of the admin user for Administration Console. If the primary Administration Console is not available 
for the authentication request, the uninstall fails. 


To force the uninstall program to skip the authentication request, enter the following command: 


Troubleshooting Installation 135 


12.9 


\Program Files\Novell\Uninstall_AccessManagerServer\UninstallAccessManagerServer. 
exe -DAM_INSTALL_AUTH_BYPASS=true 


Installing RHEL on Administration Console Fails if 
IPv6 Is Disabled 


By default IPv6 is enabled on RHEL 6.4. When IPv6 is partially disabled, eDirectory installation fails. 
You can disable IPv6 by adding the below entries to /etc/sysctl.conf file: 


+ net.ipv6.conf.all.disable_ipv6 = 1 


è net.ipv6.conf.default.disable_ipv6é = 1 


Use the lsmod | grep ipv6 command to verify if some of the IPv6 modules are still running. If this 
command returns any output, proceed with the installation only after disabling it. 
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3 Troubleshooting Upgrade 


13.1 


13.2 


13.3 


¢ Section 13.1, “Access Gateway Throws a 403 Forbidden Page Error for a Resource Protected 
by a Form Fill Policy,” on page 137 


¢ Section 13.2, “DN Is Added as Provider ID While Installing NUAS SAML Method,” on page 137 
¢ Section 13.3, “Troubleshooting Linux Administration Console Upgrade,” on page 137 


¢ Section 13.4, “Upgrading the Secondary Administration Console Fails with an Error,” on 
page 139 


¢ Section 13.5, “Issue in SSL Communication between Access Gateway and Web Applications,” 
on page 139 


¢ Section 13.6, “Administration Console Fails to Start When You Upgrade the Operating System 
After Upgrading Access Manager,” on page 139 


¢ Section 13.7, “Customized Login Pages Are Missing After Upgrading Access Manager,” on 
page 140 


Access Gateway Throws a 403 Forbidden Page 
Error for a Resource Protected by a Form Fill 
Policy 

This issue can happen if a web server returns a form with a HTTP 403 error code. Access Gateway, 


by default, returns its own custom error pages. Hence, this prevents the Form Fill feature to work. To 
workaround, go to Access Gateway > Advanced Options, enter ProxyErrorOverride off > click OK. 


DN Is Added as Provider ID While Installing NMAS 
SAML Method 


While installing the NMAS SAML method in an external user store, DN is added as Provider ID 
instead of the metadata URL. 


To resolve this issue, perform the following steps: 
1 Log in to Administration Console which has the external user store. 


2 Go to Roles and Tasks > NMAS > NMAS Login Methods > SAML Assertion > Affiliates. 


3 Select the respective Affiliate and change the provider ID to the identity provider metadata URL. 
For example, https:/Awww.trunk2.com:8443/nidp/idff/metadata. 


Troubleshooting Linux Administration Console 
Upgrade 


¢ Section 13.3.1, “Upgrade Hangs,” on page 138 
¢ Section 13.3.2, “Multiple IP Addresses,” on page 138 
¢ Section 13.3.3, “Certificate Command Failure,” on page 139 
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13.3.1 


13.3.2 


Upgrade Hangs 


If the upgrade program encounters an error while installing a component or encounters an 
unexpected condition that requires user input, the installation appears to hang. 
1 View the installation screen and determine which component is being upgraded. 
2 Change to the /tmp/novell_access_gateway directory. 
3 View the log file of the component that is being upgraded. 
Solve the problem described in the log file before continuing with the upgrade. 


For example, if the eDirectory health check fails, the edir log file indicates that the upgrade 
program is waiting for a response on whether the upgrade should continue. You should abort the 
upgrade, run ndsrepair to repair the configurations store, then restart with the upgrade process. 


4 lf the log file of the current component does not contain any errors, use the time stamps of the 
log files to determine which component just finished its upgrade and check it for errors. 


If you cannot determine which component is causing the problem: 
4a Abort the upgrade. 
4b Enter the following command: 


tail -f /tmp/novell_access_gateway 


This command tails all the files created in the specified directory. 
4c Restart the upgrade. 


Multiple IP Addresses 


If your server has multiple IP addresses, you might see the following error message during a Linux 
Administration Console upgrade: 


Failed to load any MDB driver - Error: Could not load driver /usr/lib/mdb/ 
mdbfile.so, error 9 - /usr/lib/mdb/mdbfile.so: cannot open shared object file: No 
such file or directory 


The error occurs when running Novell Audit on servers with more than one IP address. It occurs 
when the system attempts to upgrade the audit server. Systems with more than one IP address have 
problems running Novell Audit because the multiple directory database (MDB) driver does not know 
which IP address to use with eDirectory. You can point Novell Audit to a specific IP address by 
creating an MDB configuration file. 


The required filename and path for the MDB configuration file is as follows: 
/etc/mdb. conf 


To point Novell Audit to a specific IP address for eDirectory, the MDB configuration file must store the 
following parameters: 


driver=mdbds referral=eDirectory_IP_ Address. 
For example: 
driver=mdbds referral=10.10.123.45. 


You might only have one IP address, but your server might have two network adapters. If you create 
the /etc/mdb.conf file and specify your IP address, you do not encounter this error message when 
you upgrade. 


138 Troubleshooting Upgrade 


13.3.3 


13.4 


13.5 


13.6 


Certificate Command Failure 


Certificate commands are generated when you upgrade Administration Console, and you should 
ensure that they have completed successfully. In Administration Console Dashboard, click Security > 
Command Status. 


If a certificate command fails, note the store, then click Troubleshooting > Certificates. Select the 
store, then click Re-push certificates to push the certificates to the store. 


Upgrading the Secondary Administration Console 
Fails with an Error 


Upgrade of the secondary Administration Console fails with the following error: 
Configuring HTTP service... Failed to configure HTTP service: no referrals err=-634 


This issue may occur because of some eDirectory issues. You can run the script again. If you are 
accessing the console remotely, then run the script from the machine directly. 


Issue in SSL Communication between Access 
Gateway and Web Applications 


After upgrading Access Manager from 3.1 SP4 or 3.1 SP5 to 4.0.x, applications are not accessible. 
This issue happens when there is any discrepancy between the cipher suites configured for Access 
Gateway and the applications protected by this Access Gateway. To workaround this issue, see TID 
7016872. 


Administration Console Fails to Start When You 
Upgrade the Operating System After Upgrading 
Access Manager 

When you upgrade the operating system from SLES 11 SP3 to SLES 12 after upgrading Access 


Manager from 4.1 or later to 4.2, Administration Console fails to start. This issue occurs because 
eDirectory services do not start after the upgrade. 


To resolve this issue, perform the following steps: 


1 Runndsconfig upgrade at the SLES 12 server, where Administration Console is upgraded. 
This generates the necessary template files so that eDirectory starts without any issues. 

2 Runndsmanage startall. 
This starts eDirectory services on the SLES 12 server. 
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13.7 Customized Login Pages Are Missing After 
Upgrading Access Manager 


After upgrading Access Manager, you cannot view the customized login JSP pages. This happens 
when the customized JSP files are not restored or the legacy filesystem directory is not created. 


To resolve this issue, see Maintaining Customized JSP Files for Identity Server in the NetIQ Access 
Manager 4.3 Installation and Upgrade Guide. 
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VV Appendix 


+ Appendix A, “Configuring Administration Console Ports 9000 and 9001 to Listen on the Specified 
Address,” on page 143 
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Configuring Administration Console 
Ports 9000 and 9001 to Listen on the 
Specified Address 


In Access Manager 4.3, Administration Console ports 9000 and 9001 listen on 127.0.0.1 by default. 
Administration Console uses these ports for scheduling jobs. If you encounter any issue because of 
these ports listening on 127.0.0.1, such as issue with IPv6 connectivity, you can specify a different 
address by using the following Java option in the tomcat7.conf (Linux) or tomcat 7w.exe (Windows) 
file: 


Linux: /opt/novell/nam/adminconsole/conf/tomcat7.conf 


Windows: Navigate to C:\Program Files (x86)\Novell\Tomcat\bin and then double-click 
tomcat 7w.exe 


"com.microfocus.nam.adminconsole. localhost .ipaddress" 
For example: 


JAVA_OPTS="${JAVA_OPTS} - 
Dcom.microfocus.nam.adminconsole.localhost.ipaddress=10.0.0.0" 
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